Bug#277852: gcc-3.4: Please replace 'lib64' with 'lib' in gcc/config/i386/linux64.h on amd64
On 04-Oct-24 16:26, Daniel Jacobowitz wrote:
> I am aware that the amd64 port has decided to completely ignore
> standard methods of handling the multi-arch issues. However, most of
> the other changes are compatible as long as some constructs (e.g.
> rpath) are not used. The choice of dynamic loader is not one such.
> The ABI specifies:
>
> 5.2.1 Program Interpreter
>
> There is one valid program interpreter for programs conforming to the
> AMD64 ABI:
> /lib/ld64.so.1
> However, Linux puts this in
> /lib64/ld-linux-x86-64.so.2
>
> Debian should not have a different ABI than the rest of the planet.
> If you want it to live in /lib, talk to other distributions about
> switching to /lib/ld64.so.1 instead.
Thank you for your reply to my report.
The '/lib64' directory is just ugly and I want to get rid of that
or at least minimize its use (and I think I am not alone here).
To achive that, I recompiled the complete amd64/gcc-3.4 archive
using this patch and without the '/lib64' symlink in place.
The result is that the '/lib64' symlink may now be dropped without doing
any harm. Before that, the whole system stopped working when
the '/lib64' symlink was removed.
I think it is not a good decision to hard code the '/lib64' directory
into nearly every binary on the system, because this directory will
likely become deprecated or may even be dropped at a later time.
I do not want to wait for other distributions to switch to a reasonable
standard. Debian should go ahead here and choose a reasonable standard
from the beginning (but of course, it is not up to me to decide that).
Most multi-arch proposals I know of use '/lib/ld-linux-x86-64.so.2'
as the interpreter name.
Furthermore the current 'glibc' package already installs the interpreter
at this location (Gentoo libc does the same IIRC).
This is why I choose '/lib/ld-linux-x86-64.so.2' and not
'/lib/ld64.so.1'.
Regards
Andreas Jochens
Reply to: