AMD64 Linux documentation

[Jeremy Katz]

On Fri, 2003-12-12 at 11:08, Gene C. wrote:
> I have examined a number of the packages in the AMD64 taroon (which I 
> downloaded previously ... I don't want to waste bandwidth downloading the FC 
> preview until I am closer to having hardware ... maybe the test1 ISO images 
> will be available by then).  Anyway, after examining the taroon packages, I 
> am puzzled by some things:
>
> 1. I can see that having /lib - /lib64 and /usr/lib - /usr/lib64 resolves a 
> lot of problems of coexistence.

Yes, unlike the insanity that is ia64 which has you put ia32 stuff under
/emul/ia32-linux.  Which rpm also does transparently :)

> 2.  I understand that the /etc and /usr/share files do not likely matter since 
> they will be most likely identical.  However, won't rpm still complain since 
> you already have the package installed even if for a different architecture 
> (ix86 vice x86_64) ... and if not about the package then about the duplicate 
> files?  Somehow, using --force does not seem to be a good solution since it 
> overrides and lot of safety checking.

In most cases, the files are exactly the same, ie the same md5sum.  In
that case, rpm has always ignored file conflicts.  This is how kernel
packages were able to contain the same file (I forget which one it was)
for a long time and you can still have multiple kernel packages
installed at once.  It's only a problem when the files are different. 
As these are found for packages that matter for both, we're trying to
fix them.  The ones that are really hard are the header files that have
arch-specific assumptions in them.  There are a couple of approaches
that can be taken there for fixing things, but none of them are
particularly fun.  And the other fun part there is that's the sort of
things you really want to push upstream.

> 3. I see a lot of packages with /sbin, /usr/sbin, and /usr/bin files 
> (programs).  Depending on which package gets installed last will depend on 
> which architecture's program gets installed.  Now, I well believe that this 
> might be "controlable" during the anaconda install process with some hacks, 
> but how about post install updating?

Right now, it's last one installed wins.  I still lean towards having
something more deterministic (probably the addition of a
%_preferred_binary_color that you can set and gets followed in these
cases) but that's just my personal opinion on the best way out of it. 
anaconda makes sure that things end up right by ordering the x86_64
packages to always be last.  In general, you're never going to want more
than one binary installed except in a few very specific cases which
should probably be handled on a per package basis.  Otherwise, the
confusion and path fun gets to be a nitemare.

> 4. If it was only a couple of packages like glibc, maybe you could split the 
> packages of something.  But it is not ... at least it does not appear to be 
> just a few packages to me.
> 
> So how is this being resolved?  IMHO, the use of --force is not a good (let 
> alone a long term) solution ... an I believe that coexistence of 32 bit and 
> 64 bit applications is a long term situation.

Short-term the answer is --force in the cases where it's needed.  Longer
term, the answer is to fix the programs to handle being installed in
these cases.  In most cases, you're just going to care about this for
libraries -- for binaries, you're going to want one or the other, in
most cases the native with a few exceptions, mostly where the native
doesn't exist.

> One thought that occurs to me is to use the --relocate capability of rpm to 
> put stuff like /sbin into /sbin32.  Any thought given to that approach.

It leads to nitemares as far as paths, etc are concerned (which do you
prefer) as well as questions of which one a random app which has always
exec'd /sbin/foo really wants.

> Any pointers to documentation/discussion of how to handle coexistence of dual 
> architecture would be appreciated.  I have searched/browsed RedHat, Suse, and 
> IBM sites and found nothing so far (goodness ... IBM must have 10 engineers 
> creating hardware, 10 programmers creating software and 100,000 writers 
> writing about it).

There's probably some stuff in GCC land about how the toolchain handles
it, which is what the whole thing is based upon.

> One additional thought/question ... OK, so you have /lib - /lib64 and /usr/lib 
> - /usr/lib64 ... how does a program which needs a library get the "right" one 
> since they are named the same?

The right library gets chosen because although they have the same name,
they're not the same as far as what the DT_NEEDED is.  The DT_NEEDED for
a 64bit library is something like libc.so.6(GLIBC_2.3.2)(64bit) instead
of libc.so.6(GLIBC_2.3.2).  The x86_64 ldconfig can handle both ELF32
and ELF64 and so sets the caches up correctly.  The right dynamic loader
gets used because PT_INTERP gets set up correctly when the program is
build (it references /lib64/ld-linux-x86-64.so.2)

> This dual architecture support under a single OS looks tricky.  I am just 
> trying to understand how this works.  Once I have real hardware and can 
> install and play with it, perhaps it will become more obvious.

It's very tricky and not very obvious.  A lot of thought has gone into
it, though, and the current seems like the best solution of many that
were proposed.

Cheers,

Jeremy