[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 04-Oct-25 09:36, Daniel Jacobowitz wrote:
> On Mon, Oct 25, 2004 at 08:02:37AM +0200, Andreas Jochens wrote:
> > The '/lib64' was created with a 32bit system in mind which had to be 
> > supplemented by a few 64bit libraries, while the existing 32bit 
> > libraries would stay at '/lib'. The current amd64 port is different. 
> 
> Remember, this is not an invention of amd64.  See: ia64, sparc64,
> s390x, mips64.  All of which have very different scenarios for when a
> particular library format is preferred.  All of which are older than
> amd64.

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

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.

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

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.

Do you really count this patch as a "radical" departure from a 
standard? The only problem which may be caused by this, is that 
other distributions will have to provide a single symlink to run
Debian binaries. Gentoo and Ubuntu already have that symlink and 
others will almost certainly follow if Debian decides to use that. 
Furthermore, if someone really wants to run binaries from one 
distribution on another distribution, he should comply with the LSB 
specifications which provide the necessary framework regardless of this 
patch.

Thank you for taking the time to discuss this issue with me.

Regards
Andreas Jochens



Reply to: