Bug#246547: [RFC] Re: Bug#246547: glibc: amd64 support is missing
On 04-Apr-30 11:17, GOTO Masanori wrote:
> At Thu, 29 Apr 2004 17:53:06 +0200,
> Andreas Jochens wrote:
> > On 04-Apr-29 08:05, Jeff Bailey wrote:
> > > I'm a bit concerned about amd64 - Have the discussions now been settled
> > > for the whole true-64-bit-arch versus the everything-in-/libc64 thing?
> > >
> > > If you can refer me to specific mailing list postings that show
> > > concensus, that'd be great.
> > I cannot speak for others on this matter. I followed the
> > postings on the amd64 mailing list for some time and exchanged some
> > mails with others who try to make the amd64 port work. As I see it,
> > almost everybody is working in the direction of the 'pure64' port
> > at the moment (with 'lib64' as just a symlink to 'lib' and
> > without any support for 32bit libraries at this time).
> > I do not know of any kind of 'official' consensus. However, I think
> > that most people would agree that the right approach is
> > to create a functional pure64-bit port as a first step and
> > to add general multiarch support (as specified in
> > http://www.linuxbase.org/~taggart/fhs-multiarch.html) to Debian later.
> > A fully functional pure64-bit port for the amd64 architecture doesn't
> > seem to be very far away. Many packages have already made the necessary
> > changes. Most packages have been compiled for (pure64-bit) amd64
> > (I compiled about 8000 packages myself) and there is even a working
> > installer for amd64.
> I disagree with this patch. Libraries should put on /lib64 without
> symlinks because of supporting 32 bit applications. How about
> /usr/lib64 ?
> I think you should discuss about the whole support of biarch (amd64,
> mips 3 archs, ppc64, and so on). You need to look at #190399. In
> this bug report, Arnd tried to support amd64 with his first biarch
Thank you for your comments regarding my patch. I was not sure about the
best place to put the 64- and 32bit libraries on amd64 myself until I
read the multiarch proposal for the FHS and LSB standards on www.linuxbase.org
According to the multiarch proposal the right place for the libraries
will be /lib/<arch>-<os> and /usr/lib/<arch>-<os>, i.e.
/lib/x86_64-linux and /usr/lib/i386-linux in the amd64 case. Similarly
for other architectures there will be /lib/sparc-linux, /lib/sparc64-linux,
/lib/mips-linux, /lib/mips64-linux, /lib/ppc-linux, /lib/ppc64-linux etc.
Contrary to the /lib64 approach, all libraries for all different
<arch>-<os> combinations can exist simultaneously using
these general multiarch library paths. Tollef Fog Heen has written
a document (http://raw.no/debian/amd64-multiarch-2) which explains how
multiarch support could be implemented in Debian.
The older approach to put 32bit libraries into /lib and 64bit libraries
into /lib64 (and similarly for /usr/lib and /usr/lib64) leads to
problems for the amd64 port because most packages expect the native
packages in /lib where they would find only the non-native 32bit
packages. Many packages would have to be changed to support that.
A slightly saner method than /lib and /lib64 would be to use /lib32 for
32bit and /lib64 for 64bit libraries and make /lib a symlink to
the native (i.e. 64bit-) libraries on amd64.
However, the multiarch approach which supports more than two
different architectures looks even better than that.
To get things started on amd64 I strongly favor to put the
64bit libraries into /lib and /usr/lib until the multiarch issues have
been sorted out. Much work has been done in this direction and we could
have a fully functional native amd64 port really soon this way. The only
missing things at the moment are the appropriate amd64 directories on
the official ftp archives and the addition of 'amd64' to the
'Architecture:' fields in the debian/control files of a small set of
architecture specific packages.
To UNSUBSCRIBE, email to debian-glibc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com