[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 11:16, Daniel Jacobowitz wrote:
> On Mon, Oct 25, 2004 at 05:06:21PM +0200, Andreas Jochens wrote:
> 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.

The Debian amd64 port installs 64bit libraries in '/lib'. This is a
fact and this will not change. The _only_ place where the 
'/lib64' directory which is a symlink to '/lib' is used by the 
Debian amd64 port is the name of the interpreter which is specified
in gcc. This makes the whole system depend on the '/lib64' symlink
an I want to avoid that. Users have accidently removed that symlink
(sometimes by trying to install external software) which 
made the system completely unusable. I want to get rid of 
the dependency on the '/lib64' symlink to avoid that effect and to
make further changes to run external software easier (e.g. by making
/lib64 a separate directory - such a change by a package upgrade will
be nearly impossible as long as 'ln' depends on that symlink).

> 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 is supposed to show that the interpreter name is the only place
where the '/lib64' symlink is really used. This is not trivial, because
in theory lots of packages might already check for the '/lib64' during
the build process and could either FTBFS or stop running if the '/lib64'
(or '/usr/lib64') directory is not present. However, this is not the
case. It is supposed to show that we can have the well known standard 
unix filesystem layout on amd64 without any '/lib64' and symlink tricks. 

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

Come on, be realistic. If I cannot convince Debian to start using an
interpreter name in '/lib', it will be diffcult to convince somebody 
from the commercial distributions to install the symlink. 
It is a chicken and egg problem and you know that. 
However, at least Gentoo and Ubuntu (and maybe others) already have 
the necessary symlink.

> Please, tell me - has anyone discussed this compatibility issue outside
> of Debian?

There have mainly been talks about general multiarch support which
have in common that the interpreter is located in '/lib':

http://www.linuxbase.org/~taggart/multiarch.html 

specifies /lib/x86_64-linux/ld.so.2 as the interpreter name for 
multiarch. (Would you accept that one?)

If my arguments do not convince you that to get rid of the '/lib64'
dependency now, i.e. before Debian starts to officially support amd64,
would be a good move, please feel free to close this bug report.

Regards
Andreas Jochens



Reply to: