Bug#277852: gcc-3.4: Please replace 'lib64' with 'lib' in gcc/config/i386/linux64.h on amd64
On Mon, Oct 25, 2004 at 05:06:21PM +0200, Andreas Jochens wrote:
> ia64 puts 64bit libraries in '/lib' and not in '/lib64'.
> The FHS Version 2.3 summarizes the reason for this:
> "IA-64 uses a different scheme, reflecting the deprecation of
> 32-bit binaries (and hence libraries) on that architecture."
> The same reason to put 64bit libraries in '/lib' and not in '/lib64'
> is valid for amd64: 32-bit binaries are deprecated on amd64 and should
> therefore no be in '/lib'.
Oops. So I'm wrong about ia64; sorry about that :-)
> On sparc64, s390x and mips64 the '/lib64' directory may be useful,
> because on those architectures 32bit binaries are usually faster
> than 64bit binaries. Therefore those systems tend to use 32bit libraries
> in most cases while 64bit libraries are used for special purposes,
> i.e. those architectures mostly run "biarch" ports which are mostly
> 32bit based.
>
> The amd64 case is different because 64bit binaries are usually faster
> than 32bit ones on amd64 because of the larger number of available
> registers for 64bit binaries. Therefore the native 64bit port
> which does not use 32bit libraries at all makes sense for amd64.
I really don't agree that doing this based on the performance issues
makes sense. And you're wrong about mips64; the most efficient
libraries on mips64 targets are usually n32, which live in /lib32
rather than the o32 binaries in /lib. I don't know about s390x.
Or about ppc64, which does the same.
> > > There have been many discussions on this subject. I prefer to show a
> > > working solution before presenting a proposal to change an existing
> > > standard or to establish a new standard. Standards should be taken from
> > > working and proven solutions not vice versa.
> >
> > Yes, but radical departures from standards should be _talked about_.
> > By people from more than one implementor of the standard; that's what
> > makes them standards.
>
> I have to start somewhere. Take my wishlist report as a first
> try at convincing a major distribution to go the right way.
My point is that convincing one distribution is the wrong place to
start.
> Recompiling the whole distribution and showing that everything
> works and trying to get people to use it might be even a better way of
> convincing people than just talking. The subject has been talked to
> death. Something has to be done _now_, while the amd64 port and amd64
> distributions in general are not yet widely used for production
> purposes. Later it _will_ become difficult to change anything.
It's already widely used for production, in the commercial enterprise
distributions. Of course recompiling the whole distribution works;
it's only a compatibility issue. So I don't understand what that is
supposed to show.
It's been talked to death _in the wrong place_.
> Do you really count this patch as a "radical" departure from a
> standard?
Yes. I do not think the commercial distributions will provide a
symlink for compatibility with Debian, unless there is official ABI
documentation showing that this is the way to go. That's where you
should start.
Please, tell me - has anyone discussed this compatibility issue outside
of Debian?
--
Daniel Jacobowitz
Reply to: