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