[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: