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

Bug#888073: marked as done (glibc: Support amd64 systems without /lib64)

Your message dated Fri, 26 Jan 2018 22:27:22 +0100
with message-id <20180126212722.GA13069@aurel32.net>
and subject line Re: Bug#888073: glibc: Support amd64 systems without /lib64
has caused the Debian Bug report #888073,
regarding glibc: Support amd64 systems without /lib64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
888073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Source: glibc
Version: 2.26-4
Severity: wishlist

amd64 systems can work perfectly without a /lib64 directory. Since I am
unlikely to convince you to ship ld-linux-x86-64.so.2 under /lib instead
of /lib64 by default, could you allow this option with a build profile,
e.g. nolib64?

Attachment: smime.p7s
Description: S/MIME cryptographic signature


--- End Message ---
--- Begin Message --- 
On 2018-01-26 21:55, Javier Serrano Polo wrote:
> El dv 26 de 01 de 2018 a les 20:10 +0100, Aurelien Jarno va escriure:
> > It's probably not clear, let me try again. Your package provides a
> > /lib/ld-linux-x86-64.so.2 -> /lib64/ld-linux-x86-64.so.2 symlink. As 2
> > packages or more can't provide the same file, I conclude that to be able
> > to install your package your program interpreter should be installed in
> > /lib64 (and not in /lib), which is exactly what you want to avoid.
> 
> You are forgetting the claim that the example is countering. No matter
> how, can a /lib/ld-linux-x86-64.so.2 program run on your system? Does
> the provided package work on your system or not?

It does work on my system. However this package is not installable on
your system due to the /lib/ld-linux-x86-64.so.2 conflict (unless you
have yet another ugly way to do that). So it still mean you can't
provide a package that is compatible with both paths.

> El dv 26 de 01 de 2018 a les 20:42 +0100, Samuel Thibault va escriure:
> > How did it find an interpreter?
> 
> Now the workings; you may not like how it works, but it does. My kernel
> acknowledges the fact that third-party programs may require interpreters
> that do not exist, which is a problem if the base filesystem cannot be
> modified. If the interpreter does not exist, the kernel asks for
> alternatives.
> 
> In the case of amd64, there is a module which handles the
> well-known /lib64/ld-linux-x86-64.so.2. If I want to support those
> programs, I load the module with the
> alternative /lib/ld-linux-x86-64.so.2. It is like a symlink, but without
> touching the base filesystem and just for the purpose of finding an
> interpreter.
> 
> The way I see the ABIs,
> /lib64/ld-linux-x86-64.so.2, /lib/ld.so.1, /libexec/ld-elf.so.1, etc.
> are magic strings, not requirements for the filesystem. It is a kind of
> binfmt-support solution.

Thanks for the explanation. It would have been so much easier if you
had given it in the first mails. It's an ugly solution and clearly not
something we want to support, even as a build profile.

Therefore I guess we can just end the discussion. Closing the bug.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: