AMD64 Linux documentation

[Gene C.]

Is there any documentation available for the AMD64 version of Fedora Core (or 
RHEL for that matter)?  Yes, I have read the FAQ.

I am in the process of putting together a test system based on the AMD64 
(actually an opteron since it is cheaper) and the motherboard will not arrive 
until next week. So I thought I would try and do some research on AMD64 Linux 
and how it is put together.  I am especially interested in how it supports 
both 32 bit and 64 bit applications and how the file system (and other stuff) 
will be configured to handle both 32 bit and 64 bit applications.  It might 
also be nice to be able to have both 32 bit and 64 bit versions of some 
applications installed at the same time (e.g., mozilla).

The only thing I could find for RHEL 3 is an Itanium and AMD64 Installation 
Guide.  But, as far as I can see, it only talks about the Itanium with no 
mention of the AMD64/Opteron.  The only thing I could find on debian is a 
short HOWTO which basically comes down to ... install a 32 bit system and 
then install a 64 bit kernel but do not install any 64 bit application 
because they are not "stable".  Since Red Hat is marketing (and delivering) 
RHEL 3 for the AMD64/Opteron, I suspect they have worked out a lot of 
stability problems (through a lot of blood, sweat and tears on their part).

I also took a quick look at both SUSE and Mandrake but the most I could find 
was some pitches for selling their AMD64 version which will be available RSN.

I also did some browsing of the packages available in the preview version.  
> From what I could see there are a couple of new directory trees such
> as  
/lib64 and /usr/lib64 which hold the 64 bit versions of libraries with the 32 
bit version going into /lib and /usr/lib.  However, there are still conflicts 
with between the 32 bit and 64 bit version of glibc (for example) -- 
/usr/share/doc, /usr/sbin/ sbin/ and /etc which would (not easily) allow 
concurrent installation.  I took a look at some of the packages in 
taroon-amd64 and the same thing is true there.

I realize that this (Fedora Core for the AMD64) is a "work in progress" but I 
am hoping for some information as to how these this will (are being) made to 
work.  One of the great attractions of the AMD64 (at least to me) is the 
ability to run "old" 32 bit applications at the same time (on the same 
system) I am running 64 bit applications.  The AMD64 is very different from 
the Itanium since I do not need to port and rebuild my 32 bit application ... 
the only other hardware I am aware that has this dual mode (32 bit/64 bit) 
capability is the Sun Sparc.

There is a little info (not much) on the amd64 mailing list but no real 
discussion of how to resolve the package conflicts (other than using --force 
which does not make sense to me).

OK, I am hoping that some of the folks at Red Hat (and perhaps others) have 
given this some thought and have a strategy for this.
-- 
Gene

[Kjetil Mikkelborg]

Not that this will answer any of your questions, but :

Ive been running a IBM opteron based server as an fileserver/boot server
for around 6 clients in about a week now, and I actually has not noted
any problems at all.. Just installed the fedora amd64 port on it, and
wanted to test it before i downgrade it to regular fedora. But If this
stability continues, I will sure delay the downgrade as much as
possible! If I am lucky, This can even hold to fc1 amd64 comes out in a
!testing release :)

Pretty impressed.

tor, 11.12.2003 kl. 22.07 skrev Gene C.:
>  Is there any documentation available for the AMD64 version of Fedora
> Core (or 
>  RHEL for that matter)?  Yes, I have read the FAQ.
>  
>  I am in the process of putting together a test system based on the AMD64 
>  (actually an opteron since it is cheaper) and the motherboard will not arrive 
>  until next week. So I thought I would try and do some research on AMD64 Linux 
>  and how it is put together.  I am especially interested in how it supports 
>  both 32 bit and 64 bit applications and how the file system (and other stuff) 
>  will be configured to handle both 32 bit and 64 bit applications.  It might 
>  also be nice to be able to have both 32 bit and 64 bit versions of some 
>  applications installed at the same time (e.g., mozilla).
>  
>  The only thing I could find for RHEL 3 is an Itanium and AMD64 Installation 
>  Guide.  But, as far as I can see, it only talks about the Itanium with no 
>  mention of the AMD64/Opteron.  The only thing I could find on debian is a 
>  short HOWTO which basically comes down to ... install a 32 bit system and 
>  then install a 64 bit kernel but do not install any 64 bit application 
>  because they are not "stable".  Since Red Hat is marketing (and delivering) 
>  RHEL 3 for the AMD64/Opteron, I suspect they have worked out a lot of 
>  stability problems (through a lot of blood, sweat and tears on their part).
>  
>  I also took a quick look at both SUSE and Mandrake but the most I could find 
>  was some pitches for selling their AMD64 version which will be available RSN.
>  
>  I also did some browsing of the packages available in the preview version.  
>  >From what I could see there are a couple of new directory trees such as 
>  /lib64 and /usr/lib64 which hold the 64 bit versions of libraries with the 32 
>  bit version going into /lib and /usr/lib.  However, there are still conflicts 
>  with between the 32 bit and 64 bit version of glibc (for example) -- 
>  /usr/share/doc, /usr/sbin/ sbin/ and /etc which would (not easily) allow 
>  concurrent installation.  I took a look at some of the packages in 
>  taroon-amd64 and the same thing is true there.
>  
>  I realize that this (Fedora Core for the AMD64) is a "work in progress" but I 
>  am hoping for some information as to how these this will (are being) made to 
>  work.  One of the great attractions of the AMD64 (at least to me) is the 
>  ability to run "old" 32 bit applications at the same time (on the same 
>  system) I am running 64 bit applications.  The AMD64 is very different from 
>  the Itanium since I do not need to port and rebuild my 32 bit application ... 
>  the only other hardware I am aware that has this dual mode (32 bit/64 bit) 
>  capability is the Sun Sparc.
>  
>  There is a little info (not much) on the amd64 mailing list but no real 
>  discussion of how to resolve the package conflicts (other than using --force 
>  which does not make sense to me).
>  
>  OK, I am hoping that some of the folks at Red Hat (and perhaps others) have 
>  given this some thought and have a strategy for this.

[Bryan O'Sullivan]

On Thu, 2003-12-11 at 13:07, Gene C. wrote:

>  I am especially interested in how it supports 
>  both 32 bit and 64 bit applications and how the file system (and other stuff) 
>  will be configured to handle both 32 bit and 64 bit applications. 
32-bit shared libraries live in /usr/lib and /lib; 64-bit libraries live
in /usr/lib64 and so on.  Binaries all install to the usual directories
regardless of which architecture they are.

>    It might 
>  also be nice to be able to have both 32 bit and 64 bit versions of some 
>  applications installed at the same time (e.g., mozilla). 
You'd have to build separate RPMs for that.

>  I also took a quick look at both SUSE and Mandrake but the most I
> could find 
>  was some pitches for selling their AMD64 version which will be available RSN. 
Both vendors have had AMD64 distros available for a while.  SuSE was
responsible for porting Linux to AMD64 in the first place, so they did
all the "grunt work".

>  However, there are still conflicts 
>  with between the 32 bit and 64 bit version of glibc (for example) -- 
>  /usr/share/doc, /usr/sbin/ sbin/ and /etc which would (not easily) allow 
>  concurrent installation.   
There's a hack in place in the latest Red Hat version of RPM that
basically chooses 64-bit binaries in preference to 32-bit binaries when
there's a conflict.  This hack seems to apply to docs, too, but not to
some other kinds of files such as scripts.  The result is that many
packages (glibc being one) can cleanly have 32-bit and 64-bit packages
installed simultaneously, but others can't be installed bi-arch without
some crowbar work due to having inter-package dependencies that break
them (XFree86 was this way last time I checked).

>  One of the great attractions of the AMD64 (at least to me) is the 
>  ability to run "old" 32 bit applications at the same time (on the same 
>  system) I am running 64 bit applications. 
This works out well in practice for many applications, once you have the
base system installed properly and the ragged edges beaten into shape. 
I'm sure those ragged edges will get worked out over the next several
months.

	<b

[Gene C.]

On Thursday 11 December 2003 17:08, Bryan O'Sullivan wrote:
>  There's a hack in place in the latest Red Hat version of RPM
> that
>  basically chooses 64-bit binaries in preference to 32-bit binaries when
>  there's a conflict.  This hack seems to apply to docs, too, but not to
>  some other kinds of files such as scripts.  The result is that many
>  packages (glibc being one) can cleanly have 32-bit and 64-bit packages
>  installed simultaneously, but others can't be installed bi-arch without
>  some crowbar work due to having inter-package dependencies that break
>  them (XFree86 was this way last time I checked).
>
>  > One of the great attractions of the AMD64 (at least to me) is the
>  > ability to run "old" 32 bit applications at the same time (on the same
>  > system) I am running 64 bit applications.
>
>  This works out well in practice for many applications, once you have the
>  base system installed properly and the ragged edges beaten into shape.
>  I'm sure those ragged edges will get worked out over the next several
>  months. 
Yes but ... I wonder how things will work when you need to update both the 32 
bit and 64 bit versions of packages vis up2date (or whatever it becomes).

The AMD64 systems are the only one currently supported by Red Hat that seem to 
have this bimodal capability (the Sparc is not supported any longer).  I have 
no idea if the ppc64 or the s390z can concurrently run 32 bit applications.

One solution could be to breakup (make more granular) some of the packages to 
move the conflicting files into a separate binary package BUT that has to be 
a messy solution.

While the processing of getting Fedora Core "working" for AMD64 may be a bit 
messy and require some crowbaring to work, maybe (I hope, I hope, I hope), 
Fedora Core 2 may be able to be out in two architectures.


-- 
Gene

[Lamont R. Peterson]

On Thu, 2003-12-11 at 16:00, Gene C. wrote:
>  The AMD64 systems are the only one currently supported by Red Hat
> that seem to 
>  have this bimodal capability (the Sparc is not supported any longer).  I have  
Is there no SPARC version of Fedora?  Is that what you mean by "...the
SPARC is not supported any longer..."?

>  no idea if the ppc64 or the s390z can concurrently run 32 bit
> applications. 
As I understand it, Apple's G5 systems are capable of running both 64-
and 32-bit apps side by side.  The processor has all of the G4 32-bit
instructions.

The same should hold true for IBM's Power4 systems, as long as the
appropriate libraries were present for the applications, of course.
-- 
Lamont Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs <http://www.gurulabs.com/>

[Bryan O'Sullivan]

On Thu, 2003-12-11 at 15:32, Lamont R. Peterson wrote:

>  As I understand it, Apple's G5 systems are capable of running
> both 64-
>  and 32-bit apps side by side.  The processor has all of the G4 32-bit
>  instructions. 
Mac OS X is 32-bit only right now.

	<b

[Lamont R. Peterson]

On Thu, 2003-12-11 at 16:42, Bryan O'Sullivan wrote:
>  On Thu, 2003-12-11 at 15:32, Lamont R. Peterson wrote:
>  
>  > As I understand it, Apple's G5 systems are capable of running both 64-
>  > and 32-bit apps side by side.  The processor has all of the G4 32-bit
>  > instructions.
>  
>  Mac OS X is 32-bit only right now. 
Right, which is why I said "apps" above, though it was not obvious the
way I phrased it.  I was trying to point out that the G5/Power4
processors have the same multi-bit-width execution capability.  Thank
you for the clarification.

To be more clear about this...I have no idea how many MacOS X apps have
64-bit versions available.  Not too many, I would guess.  That will
change.
-- 
Lamont Peterson <lamont(a)gurulabs.com&gt;
Senior Instructor
Guru Labs <http://www.gurulabs.com/>

[Bryan O'Sullivan]

On Fri, 2003-12-19 at 11:35, Lamont R. Peterson wrote:

>  To be more clear about this...I have no idea how many MacOS X apps
> have
>  64-bit versions available. 
None.  If the kernel isn't 64-bit, it's next to impossible to have a
64-bit userland.

	<b

[Gene C.]

On Thursday 11 December 2003 18:32, Lamont R. Peterson wrote:
>  On Thu, 2003-12-11 at 16:00, Gene C. wrote:
>  > The AMD64 systems are the only one currently supported by Red Hat that
>  > seem to have this bimodal capability (the Sparc is not supported any
>  > longer).  I have
>
>  Is there no SPARC version of Fedora?  Is that what you mean by "...the
>  SPARC is not supported any longer..."? 
I believe that 6.2 was the last version that Red Hat where Red Hat supported 
the Sparc.

>  > no idea if the ppc64 or the s390z can concurrently run 32 bit
>  > applications.
>
>  As I understand it, Apple's G5 systems are capable of running both 64-
>  and 32-bit apps side by side.  The processor has all of the G4 32-bit
>  instructions.
>
>  The same should hold true for IBM's Power4 systems, as long as the
>  appropriate libraries were present for the applications, of course. 
Not surprised about the G5 or the Power4.  However, the AMD64 is the only 
architecture that Red Hat currently is trying to support dual architecture 
under a single OS (If you ignore the i386/i586/i686/athlon support).  The 
problem is that with the AMD64 you want most of the packages in the 
distribution to be 64 bit with support to run other (user) 32 bit 
applications.  The i386/i586/etc situation has most packages as i386 with 
only a very few being other architectures [IMHO far easier].
-- 
Gene

[Jeremy Katz]

On Thu, 2003-12-11 at 18:47, Gene C. wrote:
>  Not surprised about the G5 or the Power4.  However, the AMD64 is the
> only 
>  architecture that Red Hat currently is trying to support dual architecture 
>  under a single OS (If you ignore the i386/i586/i686/athlon support).  The 
>  problem is that with the AMD64 you want most of the packages in the 
>  distribution to be 64 bit with support to run other (user) 32 bit 
>  applications.   
Incorrect, we do similar on zSeries (s390x is 64-bit with 31-bit
compatibility) and i/pSeries (userspace is mostly 32-bit with some
64-bit compatibility at present) in Red Hat Enterprise Linux. 

Cheers,

Jeremy

[Gene C.]

On Thursday 11 December 2003 18:53, Jeremy Katz wrote:
>  On Thu, 2003-12-11 at 18:47, Gene C. wrote:
>  > Not surprised about the G5 or the Power4.  However, the AMD64 is the only
>  > architecture that Red Hat currently is trying to support dual
>  > architecture under a single OS (If you ignore the i386/i586/i686/athlon
>  > support).  The problem is that with the AMD64 you want most of the
>  > packages in the distribution to be 64 bit with support to run other
>  > (user) 32 bit applications.
>
>  Incorrect, we do similar on zSeries (s390x is 64-bit with 31-bit
>  compatibility) and i/pSeries (userspace is mostly 32-bit with some
>  64-bit compatibility at present) in Red Hat Enterprise Linux. 
Thanks for the info/correction Jeremy!

Having dealt with IBM mainframes for years, I can well understand that the 
zSeries hardware supports both 64-bit and 31-bit addressing (and probably 
24-bit addressing as well).  However, not having seen the distribution media, 
I am not familiar with the amount of dual packages (s390x and s390) exist in 
the distribution -- the development directory trees for s390 and s390x only 
contrain their respective packages).

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.

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.

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?

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.

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.

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).

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?

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.
-- 
Gene

[Michael K. Johnson]

On Fri, Dec 12, 2003 at 11:08:08AM -0500, Gene C. wrote:
>  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. 
Since the very beginning of RPM, it has been OK to share *identical*
files between packages.  They are refcounted and only removed when the
last package referencing them is removed.

>  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? 
Not every package is installed in both versions.  In particular, you
rarely want two versions of a program installed.

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/

[Gene C.]

On Friday 12 December 2003 11:14, Michael K. Johnson wrote:
>  On Fri, Dec 12, 2003 at 11:08:08AM -0500, Gene C. wrote:
>  > 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.
>
>  Since the very beginning of RPM, it has been OK to share *identical*
>  files between packages.  They are refcounted and only removed when the
>  last package referencing them is removed. 
I had not realized that really identical files were OK to be shared ... 
interesting and useful feature.

With respect to different architectures ... won't rpm complain on installing 
both (e.g., zlib) even if no conflicts?  Every so ofter I forget and try to 
update glibc with a simple rpm -Fvh glibc-* and both the i386 and i686 
packages in the path ... this does not work (or has not in the past).

>  > 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?
>
>  Not every package is installed in both versions.  In particular, you
>  rarely want two versions of a program installed. 
Granted, some packages with be either/or but not both.  However, at least some 
of the packages will require both to support both architectures -- glibc for 
example.  Maybe I do not understand something.  Can the x86_64 version of 
glibc support its libraries being used by a 32 bit application?  The same 
question can be stated in the opposite direction -- can a 32 bit library 
support being called by a 64 bit application?

To restate my question in the previous message -- how about using rpm 
--relocate oldpath=newpath to resolve some of the conflicts?
-- 
Gene

[Jeremy Katz]

On Fri, 2003-12-12 at 11:45, Gene C. wrote:
>  With respect to different architectures ... won't rpm complain on
> installing 
>  both (e.g., zlib) even if no conflicts?  Every so ofter I forget and try to 
>  update glibc with a simple rpm -Fvh glibc-* and both the i386 and i686 
>  packages in the path ... this does not work (or has not in the past). 
The i386 and i686 packages share files that conflict (/lib/libc.so.6 for
example).  The i686 and x86_64 packages have different files
(/lib/libc.so.6 vs /lib64/libc.so.6) and so you don't hit the problem. 
There are also different rules for handling conflicts of ELF32 vs ELF64
files than just ELF32 vs ELF32 if you have %_transaction_color set
appropriately.

>  > > 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?
>  >
>  > Not every package is installed in both versions.  In particular, you
>  > rarely want two versions of a program installed.
>  
>  Granted, some packages with be either/or but not both.  However, at least some 
>  of the packages will require both to support both architectures -- glibc for 
>  example.  Maybe I do not understand something.  Can the x86_64 version of 
>  glibc support its libraries being used by a 32 bit application?  The same 
>  question can be stated in the opposite direction -- can a 32 bit library 
>  support being called by a 64 bit application? 
No, you need both libraries.  But they end up in different paths and so
there's no conflict.  

>  To restate my question in the previous message -- how about using rpm
>
>  --relocate oldpath=newpath to resolve some of the conflicts? 
Libraries should be built so that they don't have a problem (since the
canonical location for native system libraries on e.g. x86_64 is lib64
instead of lib).  For binaries, it really is something you want to
choose and not have two separate sets in two separate paths that may or
may not be in your PATH and ... :-)

Cheers,

Jeremy

[Jakub Jelinek]

On Fri, Dec 12, 2003 at 12:04:00PM -0500, Jeremy Katz wrote:
>  Libraries should be built so that they don't have a problem
> (since the
>  canonical location for native system libraries on e.g. x86_64 is lib64
>  instead of lib).  For binaries, it really is something you want to
>  choose and not have two separate sets in two separate paths that may or
>  may not be in your PATH and ... :-) 
Yeah, wonder why user should always think if he wants to run 32-bit or
64-bit ls.  They both give the same output, so the one that is faster
is usually the ultimate choice.
On AMD64, usually 64-bit programs are faster than 32-bit (bigger memory
footprint is overweighted by additional registers, %rip addressing etc.).
On e.g. SPARC or PPC it is the opposite (bigger memory footprint makes
64-bit programs slower).  So, on AMD64 you want most things 64-bit,
plus 32-bit libraries and some programs so that you can run things
which are only 32-bit.  I'm very curious if 64-bit OOo would be a win
on AMD64 though, given its insane memory footprint.
On SPARC/PPC, you want most of the programs 32-bit, with the exception
of programs which need bigger address space, do lots of computation
in 64-bit arithmetics or are too much connected with the kernel (so that
data doesn't have to be converted back and forth, for specialized utilities
the conversion code may not even be written).

	Jakub

[Gene C.]

First of all, thank you Jeremy, Jakub, et al ... this is excellent 
information!  So lets see if I understood what you said --

1.  For libraries, I believe I understand now that the loader determines which 
set of libraries (32 bit or 64 bit) are needed and does the right thing.

2.  For myself (and I suspect many others also), and AMD64 system will be used 
and an run mostly 64 bit applications.  If I need to compile (or build an 
rpm) for a 32 bit application, I will do that on a 32 bit system so I will 
not need any 32 bit devel (header) files.  If I install the 64 bit devel 
packages, then I should get the appropriate header and other data files for 
my 64 bit system.

3.  For non-header data files (/etc or /usr/share), the md5sum values should 
match so rpm will ignore conflicts.

4.  Now for the /bin, /sbin, /usr/bin, /usr/sbin, and /usr/X11R6/bin program 
files, you really want the 64 bit versions ... unless there is no 64 bit 
version in which case you want the ix86 version.  You really do not want any 
of the "color 0" 32 bit files installed if there is a 64 bit version.

I assume that anaconda can be/has been tweaked to do the right thing about 
making sure the the x86_64 package is installed last.

I would assume that up2date (or whatever its replacement become) may be harder 
to do but is still do-able.

The good news is that rpm -Uvh --force glibc-2* will most likely do the right 
thing also do to sort order (good thing the packages are not "amd64" instead 
of "x86_64").

The bad news is that an individual could still screw things up and make a 
system unusable.  For example, if the packages are installed in the wrong 
order.  There should be some deterministic way to tell rpm to NOT install any 
color 0 files of the "lower order" architecture no matter what order the 
packages are installed.

I also suspect that rpm -Fvh is not going to work (or work correctly) where I 
need to install "the same" package name/version/release but for both 
architectures.

I do not know how many copies of RHEL 3 for the amd64 Red Hat has sold so far 
but do you have any experience as far as users updating their systems ... has 
anyone screwed their systems by installing updates in the "wrong order"?

BTW, is there some manuals documenting this (package application order, etc.) 
which come with the RHEL systems (but are not open source)?  Since I have not 
purchased a copy (yet), I have not seen the documentation that comes with 
these systems.
-- 
Gene

[Jakub Jelinek]

On Fri, Dec 12, 2003 at 11:45:59AM -0500, Gene C. wrote:
>  Granted, some packages with be either/or but not both.  However, at
> least some 
>  of the packages will require both to support both architectures -- glibc for 
>  example.  Maybe I do not understand something.  Can the x86_64 version of 
>  glibc support its libraries being used by a 32 bit application?  The same 
>  question can be stated in the opposite direction -- can a 32 bit library 
>  support being called by a 64 bit application? 
The files in rpms are colored by rpm.  Data files or binaries have one
color 0, 32-bit shared and .a libraries color 1 and 64-bit shared and .a
libraries color 2.
When you are installing a rpm which is already installed with the same NEVR,
but different architecture, rpm will I believe ATM overwrite color 0 files
and install the opposite color from the other already used, so that you can
have both color 1 and color 2 of the same shared library, but only one
color 0 file.  Which means why installing the preferred arch last matters.
At least the original intent was that the order doesn't matter and through
rpm configuration files or perhaps some package tag as well you can
tell rpm which arch it should prefer (32-bit vs. 64-bit) for all packages or
even on a package by package basis.
This would change in rpm behaviour in that when installing the non-preferred
arch second, it would only install color != 0 files instead of all files.

	Jakub

[Elliot Lee]

On Fri, 12 Dec 2003, Gene C. wrote:

>  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? 
/sbin/ldconfig has to be the 64-bit version. This version knows how to
read info from both 32-bit and 64-bit libraries in lib and lib64 dirs.  
The library info is written into /etc/ld.so.cache. The application's
dynamic linker (/{lib,lib64}/ld-linux*.so*) looks through ld.so.cache and
only pays attention to the libraries that match the architecture of the
application.

-- Elliot
http://www.barbiecollectibles.com/shop/product.aspx?sku=B3449
One ring to rule the malls, a website to supply them. The Tolkien "Ken
and Barbie" dolls - now 60 bucks can buy them!

[Gene C.]

On Friday 12 December 2003 11:24, Elliot Lee wrote:
>  On Fri, 12 Dec 2003, Gene C. wrote:
>  > 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?
>
>  /sbin/ldconfig has to be the 64-bit version. This version knows how to
>  read info from both 32-bit and 64-bit libraries in lib and lib64 dirs.
>  The library info is written into /etc/ld.so.cache. The application's
>  dynamic linker (/{lib,lib64}/ld-linux*.so*) looks through ld.so.cache and
>  only pays attention to the libraries that match the architecture of the
>  application. 
Aaah ... the magic explained ... now this is beginning to make sense.  If 
nobody has already done it (or gets to it sooner), maybe I will pull all this 
good info (and some I am finding reading through the SUSE mailing lists) into 
a faq or something.  BUT, I want to get some real hardware experience first 
[chomping at the bit waiting for my motherboard].
-- 
Gene

[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

[Jakub Jelinek]

On Fri, Dec 12, 2003 at 11:58:52AM -0500, Jeremy Katz wrote:
>  > 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) 
DT_NEEDED contains just libc.so.6 for both 32-bit and 64-bit.  Symbol
version needs are in .gnu.version_r and 32-bit/64-bit is simple - a 32-bit
program/shared library always wants 32-bit dependencies, 64-bit
program/shlib wants 64-bit libraries.
What you wrote above are what rpm's provides/requires contain.

	Jakub

[Justin M. Forbes]

On Thu, Dec 11, 2003 at 04:07:14PM -0500, Gene C. wrote:
>  Is there any documentation available for the AMD64 version of Fedora
> Core (or 
>  RHEL for that matter)?  Yes, I have read the FAQ.
>   
At this point, documentation is lagging, but should be updated before an
actual gold release of Fedora Core for AMD64.  I have been spending most of
my time tracking down bugs and testing, instead of documenting.  With a day
job, and family, I have to do what I can in the time I have.  That said I
will try to answer some of your questions here.

>  I am especially interested in how it supports 
>  both 32 bit and 64 bit applications and how the file system (and other stuff) 
>  will be configured to handle both 32 bit and 64 bit applications.  It might 
>  also be nice to be able to have both 32 bit and 64 bit versions of some 
>  applications installed at the same time (e.g., mozilla).
>   
Currently, all applications are 64bit with the following noted exceptions:
- Open Office.org is 32bit only, and will remain so until some of the code
  is changed.  It still functions quite well in my testing.

- Mozilla, originally was installed both 64bit and 32bit, but that may
  change before test1 release, with the removal of 64bit.  32bit is
  required for Open Office.org, and 32bit plugins (many of which are not open
  source or available 64bit yet) will not work in 64bit unless someone takes
  the time to write a thunking layer.  As a result, epiphany must go 32bit as
  well.

Libraries are a different issue, and libtool handles the 64bit/32bit
concurrent install deal.  32bit libraries are provided to support many of
the majr apps, and I have 32bit Java/flash player, and mp3 support running
on my system just fine.  32bit libs which are not required by the above
mentioned 32bit apps, and which are not in extremely high use by apps which
I would expect people to use 32bit still are not going to be included in
the distribution because if they are not wideley tested, we cannot
guarantee their funtionality. That said, there is no voodoo required for
installation of most libs anyway.

In the kernel, the required 32bit syscalls should be implemented, and I
will be glad to look at any which seem to be missing.
 
>  The only thing I could find on debian is a 
>  short HOWTO which basically comes down to ... install a 32 bit system and 
>  then install a 64 bit kernel but do not install any 64 bit application 
>  because they are not "stable".  Since Red Hat is marketing (and delivering) 
>  RHEL 3 for the AMD64/Opteron, I suspect they have worked out a lot of 
>  stability problems (through a lot of blood, sweat and tears on their part).
>   
Actually 64bit seems to work well in most cases, which is why we are
looking at a mostly 64bit system here (With the above noted exceptions).
  
>  I also did some browsing of the packages available in the preview
> version.  
>  From what I could see there are a couple of new directory trees such as 
>  /lib64 and /usr/lib64 which hold the 64 bit versions of libraries with the 32 
>  bit version going into /lib and /usr/lib.  However, there are still conflicts 
>  with between the 32 bit and 64 bit version of glibc (for example) -- 
>  /usr/share/doc, /usr/sbin/ sbin/ and /etc which would (not easily) allow 
>  concurrent installation.  I took a look at some of the packages in 
>  taroon-amd64 and the same thing is true there.
>   
We are looking to resolve any conflicts where they exist.  Note that
/usr/share/doc and often times /etc does not necessarily mean conflict.  If
the files are the exact same, then there is no conflict, and every package
has what it installed.  That said there are a few issues being addressed
which is one of the reasons we are still in a preview release and not a
full test1.
 
>  I realize that this (Fedora Core for the AMD64) is a "work in
> progress" but I 
>  am hoping for some information as to how these this will (are being) made to 
>  work.  One of the great attractions of the AMD64 (at least to me) is the 
>  ability to run "old" 32 bit applications at the same time (on the same 
>  system) I am running 64 bit applications.  The AMD64 is very different from 
>  the Itanium since I do not need to port and rebuild my 32 bit application ... 
>  the only other hardware I am aware that has this dual mode (32 bit/64 bit) 
>  capability is the Sun Sparc.
>   
32bit compatability is a strong feature of this platform, we are looking to
keep that.

>  OK, I am hoping that some of the folks at Red Hat (and perhaps
> others) have 
>  given this some thought and have a strategy for this. 
It is being thought, and addressed.  Any feedback, recommendations, or
patches are definately appreciated.

Justin M. Forbes

[Gene C.]

On Thursday 11 December 2003 17:10, Justin M. Forbes wrote:
>  It is being thought, and addressed.  Any feedback, recommendations,
> or
>  patches are definately appreciated. 
Thanks for the info!

To make reasonable comments, etc. I will need to wait until I get my new 
system up and hobbling which will be another week to ten days.
-- 
Gene

64-bit OpenOffice.org help wanted [Was: Re: AMD64 Linux documentation]

[Dan Williams]

Speaking (unofficially) for the OpenOffice.org project, we would
_greatly_ appreciate any help on making OOo 64-bit clean.  Some work has
been done but there is not much momentum at this time.  There is a
branch set up to accept 64-bit changes and the commit rules for it are
not very strict.

The main problems are identifying where 64-bit issues were not taken
into account, for example when the wrong types are used for variables
(an address passed in a sal_uint32 rather than a real 64-bit pointer
type), and the bridge code, which requires some knowledge of assembly
and the C++ ABI for the particular 64-bit platform.  There will likely
need to be back-and-forth on mailing lists with the original authors or
current maintainers of the code to see what their intentions with
certain variables were when the types are not clear.

If anyone is interested in helping out, and has or has access to the
required hardware (either Sparc64, Alpha, PPC970, AMD64, Itanium) on
_any_ OS, please either contact me or subscribe to
dev(a)porting.openoffice.org for pointers or more information.

Dan

On Thu, 2003-12-11 at 17:10, Justin M. Forbes wrote:
>  - Open Office.org is 32bit only, and will remain so until some of the
> code
>    is changed.  It still functions quite well in my testing.

64-bit OpenOffice.org help wanted [Was: Re: AMD64 Linux documentation]

[Bill Rugolsky Jr.]

On Fri, Dec 12, 2003 at 09:53:25AM -0500, Dan Williams wrote:
>  If anyone is interested in helping out, and has or has access to the
>  required hardware (either Sparc64, Alpha, PPC970, AMD64, Itanium) on
>  _any_ OS, please either contact me or subscribe to
>  dev(a)porting.openoffice.org for pointers or more information. 
Two random thoughts:

(1) By placing program+data above 4GB in the address space,
    one should locate many sizeof(ptr) == 4 assumptions rather
    quickly by trapping on access to low addresses.

(2) An AMD64 version of Valgrind would help.

Regards,

	Bill Rugolsky