Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, le lun. 16 sept. 2019 23:55:24 +0200, a ecrit:
> El dl 16 de 09 de 2019 a les 22:53 +0200, Samuel Thibault va escriure:
> > How can it start without its interpreter in /lib64?
> 
> This is explained in the report.

Ok, now I remember that discussion (from one year ago...). It seems I
should just have ignored the mail you sent today, since everything was
already discussed.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, le lun. 16 sept. 2019 21:52:31 +0200, a ecrit:
> El dv 26 de 01 de 2018 a les 19:18 +0100, Samuel Thibault va escriure:
> > Can you run the attached program?
> 
> Yes, I can. It looks like the program is true from GNU coreutils 8.28.

How can it start without its interpreter in /lib64?  What does
ldd ./true print?

Samuel

Processed: Re: Bug#888073: glibc: Support amd64 systems without /lib64

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unarchive 888073
Bug #888073 {Done: Aurelien Jarno } [src:glibc] glibc: 
Support amd64 systems without /lib64
Unarchived Bug 888073
> submitter 888073 !
Bug #888073 {Done: Aurelien Jarno } [src:glibc] glibc: 
Support amd64 systems without /lib64
Changed Bug submitter to 'javier--j3tyas0zmadh4isvtuv7artbn2z...@jasp.net' from 
'javier--ryqcowxjkcug7xjmmivj70vapc5...@jasp.net'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
888073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#888073: glibc: Support amd64 systems without /lib64

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unarchive 888073
Bug #888073 {Done: Aurelien Jarno } [src:glibc] glibc: 
Support amd64 systems without /lib64
Unarchived Bug 888073
> submitter 888073 !
Bug #888073 {Done: Aurelien Jarno } [src:glibc] glibc: 
Support amd64 systems without /lib64
Changed Bug submitter to 'javier--ryqcowxjkcug7xjmmivj70vapc5...@jasp.net' from 
'javier--7c8frosbhwv6hrgym4mlhjbycgp...@jasp.net'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
888073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#888073: glibc: Support amd64 systems without /lib64

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 888073 wontfix
Bug #888073 {Done: Aurelien Jarno } [src:glibc] glibc: 
Support amd64 systems without /lib64
Added tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
888073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz]

Hi,

On Tue, 30 Jan 2018, Javier Serrano Polo wrote:

> > But I fear for /lib64/ld-linux-x86-64.so.2 it's too late,
> 
> It is never too late. Nowadays, there are no interoperability problems,
> as I have proved in this bug report.

hmm?  Here let me show you the interop problem with your suggestion:

% gcc -Wl,-dynamic-linker,/lib/ld-linux-x86-64.so.2 -o hello ~/src/hello.c
% readelf -l hello | grep Reque
  [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]
% ./hello
bash: ./hello: No such file or directory
% ls /lib/ld-linux-x86-64.so.2
ls: cannot access /lib/ld-linux-x86-64.so.2: No such file or directory

> Let us wait for your users to
> complain about manually creating a symlink.

So, uhm, you think it's acceptable to force everyone else to create a 
symlink because it's not acceptable to you?


Ciao,
Michael.

Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz]

Hi,

On Tue, 30 Jan 2018, Javier Serrano Polo wrote:

> El dl 29 de 01 de 2018 a les 16:24 +, Michael Matz va escriure:
> > Is does, but draft means many things, and for the psABI doesn't include 
> > "making backward incompatible changes is okay".
> 
> I am asking people to be nice, not requiring them to modify their
> systems. Let me try a new proposal:
> 
> 5.2.1
> Systems conforming to the AMD64 ABI may want to support
> the /lib/ld-linux-x86-64.so.2 path name, which is preferred in
> multiarch.
> 
> Appendix A.1
> Systems conforming to the AMD64 ABI may want to support
> lib/x86_64-linux-gnu subdirectories for the libraries, which are
> preferred in multiarch.
> 
> This way, people that want to help will not be frowned upon.
> Could you do another assessment?

I think the addition to A.1 along the above lines would be fine.

But the change of 5.2.1 really can't be done.  Yes, the above wording 
makes it optional, so it sounds harmless, but it isn't, for the reasons I 
already called out: as soon as we allow executables with 
/lib/ld-linux-x86-64.so.2 as PT_INTERP to be conforming (even optionally) 
we split the world (into those that do support it, as allowed, and those 
that don't, as also allowed).  That must not happen.  We could fix that 
split by not only allowing, but instead _requiring_ that new name to exist 
on all conforming implementations.  Then the world won't be split, but it 
entails changes for everyone wanting to conform to the (newest version of 
the) psABI for dubious benefit, and so isn't something we would want 
either.

Perhaps we still can do something about the x32 program interpreter 
(currently defined to sit in /libx32/ld-linux-x32.so.2).  That is a 
relatively young addition and not many people use x32, so that could be 
moved to /lib to not repeat the problem of forcing a /libx32 directory on 
everyone even if they have other mechanisms.

But I fear for /lib64/ld-linux-x86-64.so.2 it's too late, it'd create 
larger problems (conforming programs not starting everywhere conforming) 
than it fixes (the cosmetic problem of a mostly empty /lib64 directory 
having to exist).


Ciao,
Michael.

Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz]

Hi,

On Mon, 29 Jan 2018, Javier Serrano Polo wrote:

> El dl 29 de 01 de 2018 a les 13:43 +, Michael Matz va escriure:
> > To see why that is so suppose I'm changing my compiler to use a different 
> > calling convention in which the first argument is passed in %rsi and the 
> > second in %rdi, and otherwise it's all the same.
> 
> Could you tell me why on earth would you want to do that? Is there any 
> speed advantage?

No, of course not.  It was an easy to understand change to demonstrate a 
point I was trying to make.  Obviously I failed.  If I had known that 
you'd be triggered by the senselessness of the proposal I'd have made a 
different one: making some of the floating point regs be callee saved, 
which indeed would help benchmarks quite some.  The way it's now 
(everything caller saved) is actually an artifact of the first 
implementations of the x86-64 insn set, and in retrospect was not the best 
choice.  We _still_ won't make a change like that, even though it'd have a 
comparatively large advantage.

> You are comparing a function-calling convention with a 
> filesystem requirement.

No, I compared an ABI change with an ABI change.

> There is an interest in dropping /lib64 and 
> maintain interoperability, and I find it legitimate.

Dropping /lib64 basically means dropping interoperability.

> > I recompile my whole system and I adjust all the various assembler 
> > snippets that have it hard-coded.
> 
> Yet another person that believes I must recompile my whole system.
> 
> > Does it make 
> > sense to encode this new calling convention in the psABI?
> 
> Give me the reason for the new calling convention and I will tell you
> whether it makes sense.

You realized that this was a rhethoric question, right?  I assume so from 
you removing my "No.", so what's your point?

> > So, while you might say that putting the loader into an alternative path 
> > is a maintainers choice, it's a (badly advised) maintainers choice of not 
> > following the psABI, not a good reason to change it.
> 
> Cleaner filesystem and multiarch simplicity. We have different views of
> what constitutes good advice.

Obviously.

> > So, no, we can't change the psABI in that respect without 
> > repercussions for all systems claiming to be conforming, which is a 
> > bad idea for an ABI that's already nearly 20 years old.
> 
> Sorry, I thought "Draft Version" meant to be a draft.

Is does, but draft means many things, and for the psABI doesn't include 
"making backward incompatible changes is okay".

> Also, I must have misunderstood the following:
> 
> The System V Application Binary Interface will evolve over time
> to address new technology and market requirements, and will be
> reissued at intervals of approximately three years. Each new
> edition of the specification is likely to contain extensions and
> additions that will increase the potential capabilities of
> applications that are written to conform to the ABI.

Indeed.  We should probably remove this paragraph.

> The only repercussion you are talking about is that systems will not be 
> able to make a claim if they do not adapt to the new version. There are 
> no real interoperability issues, as my previous counterexample proves.

You gave no counterexamples.  You explained the interop problems away by 
stating that "non-evolving" systems merely need to not claim compatibility 
with the newest version and all will be fine.

> I guess it is too much for distros to ship a symlink that would help 
> Debian-based systems to get rid of /lib64.

Yes, it is.  We basically need to make a choice between two things:
(a) change the psABI -> debian can get rid of /lib64 (but see below), 
everybody else needs to add the new loader name (at least if they want 
to "evolve"), or
(b) don't change the psABI -> no changes anywhere

A change in an psABI necessarily needs to have a very high barrier to 
entry, so it needs to have some very sound and large advantages.  Let's 
look at the advantage of (a): debian can get rid of a filename (and 
possibly directory), everybody else needs to add a filename.  Even that 
doesn't sound like a very large advantage considering everything.  But 
debian can't _actually_ get rid of the dir and filename, because not all 
software is compiled on debian, so 3rd party software conceivably would 
continue to use the current loader name.  In the name of cleanliness you 
probably would move that "old" loader name into some new subpackage of 
glibc so that you only need it when such 3rd party apps are actually 
installed.  But still you wouldn't be able to get rid of it wholly.  
So now you've made an ABI change that resulted in adding a name for 
everybody, plus a new subpackage.  Even less an advantage.  You also 
create confusion (if not about anything else, then at least about which 
ABI versions a system is conforming to), which is something that 
absolutely must be avoided in an ABI.

Bug#888073: glibc: Support amd64 systems without /lib64

[Michael Matz]

Hi,

On Fri, 26 Jan 2018, Javier Serrano Polo wrote:

> It would be nice if you answered the question about appendix A.1.
> 
> So, we have five people who state or imply that either my amd64 systems 
> do not exist or they are unavoidably incompatible with systems depending 
> on a /lib64 directory.
> 
> My systems obviously exist. To the claim that I cannot run a /lib64 
> program without rebuilding, the answer is easy to say: try my system. To 
> the claim that applications from my system will not run anywhere else, I 
> can provide a counterexample: you can install the attached package.
> 
> Would you accept the evidence? Is /lib64 still a mistake or rather a 
> maintainer's choice?

Just because your system works fine with deviations from the psABI (as it 
contains code or data to make it work with these deviations) doesn't imply 
that any changes in the psABI are required or advised.

To see why that is so suppose I'm changing my compiler to use a different 
calling convention in which the first argument is passed in %rsi and the 
second in %rdi, and otherwise it's all the same.  I recompile my whole 
system and I adjust all the various assembler snippets that have it 
hard-coded.

I will end up with a system that works fine; just like you.  Does it make 
sense to encode this new calling convention in the psABI?  No.

The whole point of a defined psABI is that you can move an executable 
from one compatible system to another different but also 
psABI-compatible system and rightfully expect that to work (given further 
constraints, of course).  Encoding alternatives for the dynamic loader 
into the psABI defeats this purpose.  A psABI-compliant system then 
suddenly wouldn't only have to provide /lib64/ld-linux-x86-64.so.2, but 
also your proposed file; i.e. alternatives in an ABI are actually 
additional requirements on the system (they're alternatives only for a 
particular file).  If a system wouldn't do that then it can't claim to be 
psABI-compatible anymore as there would exist executables which can't be 
loaded on it.

So, while you might say that putting the loader into an alternative path 
is a maintainers choice, it's a (badly advised) maintainers choice of not 
following the psABI, not a good reason to change it.

This is slightly different from the choice of not following the suggestion 
in the psABI of putting libraries into **/lib64, like the multiarch 
approach is doing.  It is different because these path names are 
configurable as search paths in the loader configuration files (and were 
already configurable at the time multiarch was invented) and not directly 
encoded into the ELF files.  (Ignoring DT_RPATH and DT_RUNPATH of course).

So, no, we can't change the psABI in that respect without repercussions 
for all systems claiming to be conforming, which is a bad idea for an ABI 
that's already nearly 20 years old.


Ciao,
Michael.

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on sam. 27 janv. 2018 17:00:14 +0100, wrote:
> El ds 27 de 01 de 2018 a les 16:07 +0100, Samuel Thibault va escriure:
> > Putting the interpreter meaning in the kernel means putting it where it
> > is not expected to be found.
> 
> Do you know that the kernel is the component that loads the ELF
> interpreter?

So what?

People expect to be able to interpret these string as path names in the
filesystem. Making it mean something else means hiding.

Period, no point answering me again.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on sam. 27 janv. 2018 16:02:15 +0100, wrote:
> El ds 27 de 01 de 2018 a les 09:41 +0100, Samuel Thibault va escriure:
> > And you hide that in the kernel,
> 
> We have different concepts of the meaning of hiding. Following your
> idea, binary formats are hidden in the kernel; to me, they are available
> under /proc/sys/fs/binfmt_misc.

That's where they are expected to be found.

Putting the interpreter meaning in the kernel means putting it where it
is not expected to be found. That's called hiding.

> > while the ABI says it's a path.
> 
> Let us see the specification:[1]
> 
> PT_INTERP
> The array element specifies the location and size of a
> null-terminated path name to invoke as an interpreter.
> 
> This is exactly what I am doing: using a path name to "invoke as an
> interpreter". No actual requirement is placed upon the filesystem.

"path name" means on the usual filesystem, just like in the rest of the
document.  If you don't agree on this, there is no point in discussing
more.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on sam. 27 janv. 2018 04:02:54 +0100, wrote:
> > > 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.
> > 
> > That's hiding the actual ABI meaning.
> 
> I do not think so. The ABI is just an interface, it says: "My executable
> will ask for this interpreter". I say: "Okay, let me handle the
> implementation details".

And you hide that in the kernel, while the ABI says it's a path.

> I will not hide this fact. Tools like gdb and valgrind fail with /lib64
> programs, which is not a problem since I usually recompile to fix a bug
> or a leak.

You can't always recompile programs.

> In the unusual case that I must audit /lib64 programs, I grab
> a read-write environment and add a symlink. If there were complaints, I
> would adapt those tools.

You can't always adapt tools.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 21:55:52 +0100, wrote:
> 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.

So you are hiding some things. Not the best thing to do, in my opinion.

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

That's hiding the actual ABI meaning.

Samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 20:38:07 +0100, wrote:
> > But what about the converse? Can you run the attached program?
> 
> Not yet:
> 
> ./true: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./true)

How did it find an interpreter?

If I drop /lib64 on my system, I can't execute it.

samuel

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-26 19:54, Aurelien Jarno wrote:
> On 2018-01-26 19:05, Javier Serrano Polo wrote:
> > My systems obviously exist. To the claim that I cannot run a /lib64
> > program without rebuilding, the answer is easy to say: try my system.
> > To the claim that applications from my system will not run anywhere
> > else, I can provide a counterexample: you can install the attached
> > package.
> 
> Your package provides a /lib64 library, which is exactly what you want
> to avoid. The binary alone doesn't work, which is exactly my point.

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.

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

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-26 19:05, Javier Serrano Polo wrote:
> X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
> a...@suse.de
> 
> El dv 26 de 01 de 2018 a les 08:39 +0100, Andreas Jaeger va escriure:
> > No, this is not possible - it would break binary compatibility. The path
> > is hardcoded into each binary and if you change it, your application
> > will not run anywhere else,
> 
> It would be nice if you answered the question about appendix A.1.
> 
> So, we have five people who state or imply that either my amd64 systems
> do not exist or they are unavoidably incompatible with systems depending
> on a /lib64 directory.

We never said that your system doesn't exist. We said you have to
rebuild all binaries to get of /lib64. It's what your package shows:

$ readelf -e hello-nolib64 | grep interpret
  [Requesting program interpreter: /lib/ld-linux-x86-64.so.2]

> My systems obviously exist. To the claim that I cannot run a /lib64
> program without rebuilding, the answer is easy to say: try my system.
> To the claim that applications from my system will not run anywhere
> else, I can provide a counterexample: you can install the attached
> package.

Your package provides a /lib64 library, which is exactly what you want
to avoid. The binary alone doesn't work, which is exactly my point.

> Would you accept the evidence? Is /lib64 still a mistake or rather a
> maintainer's choice?

/lib64 is being compatible with everybody in both directions, you like
it or not. Your system is not compatible with others. We do not want
that.

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

Bug#888073: glibc: Support amd64 systems without /lib64

[Samuel Thibault]

Javier Serrano Polo, on ven. 26 janv. 2018 19:05:38 +0100, wrote:
> X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
> a...@suse.de
> 
> El dv 26 de 01 de 2018 a les 08:39 +0100, Andreas Jaeger va escriure:
> > No, this is not possible - it would break binary compatibility. The path
> > is hardcoded into each binary and if you change it, your application
> > will not run anywhere else,
> 
> It would be nice if you answered the question about appendix A.1.
> 
> So, we have five people who state or imply that either my amd64 systems
> do not exist or they are unavoidably incompatible with systems depending
> on a /lib64 directory.

Count a sixth person :)

> My systems obviously exist. To the claim that I cannot run a /lib64
> program without rebuilding, the answer is easy to say: try my system.
> To the claim that applications from my system will not run anywhere
> else, I can provide a counterexample: you can install the attached
> package.

Yes. But what about the converse? Can you run the attached program?

Samuel


true
Description: Binary data

Bug#888073: glibc: Support amd64 systems without /lib64

[Adam Conrad]

On Wed, Jan 24, 2018 at 10:57:20PM +0100, Javier Serrano Polo wrote:
> El dc 24 de 01 de 2018 a les 22:40 +0100, Sven Joachim va escriure:
> > Well, then you have to live with /lib64.
> 
> I do not live with /lib64. You do not have to live with /lib64 unless
> you want to.

That path is baked into every single x86-64 binary compiled by any
compiler that builds for the well-defined GNU/Linux x86-64 ABI.  You
are free to patch all your compilers and your libc to build a system
that works differently, but you won't be ABI-compatible with the rest
of the Linux world, and it's nonsensical to expect Debian to make it
easy to build such a non-compatible system.

I've spent a lot of time dealing with ld.so paths upstream, and we
all agree that, given a time machine, we'd fix them all to be in /lib
and have unique names (see armhf or arm64 for examples), but while we
can change future ABIs, it's just not feasible to change an ABI that
has been in heavy use for well over a decade.

I appreciate that you think having a directory with one file in it is
ugly.  If you want to patch your local system and rebuild it all to
avoid that, go nuts.  Seems like overkill, but who am I to judge?  As
a Debian bug, however, even a wishlist one, this should be a wontfix.

... Adam

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-24 21:05, Javier Serrano Polo wrote:
> X-Debbugs-CC: cl...@debian.org
> 
> El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure:
> > The dynamic linker path is part of the
> > x86-64 ABI and is present in all ELF executables.
> 
> I am aware that the original specification has that quirk, but it was
> made without multiarch in mind. Would you choose /lib64 if you could
> decide? I would not. I think that if there is a will this can be fixed.

At the time the ABI has been written, multiarch was almost not existing.
Of course with different information you take different decision.

> Other architectures are easy to see. For instance, m68k and powerpc
> conflict with /lib/ld.so.1. amd64's interpreter does not conflict, but
> all interpreters should be under /lib. I see /lib64 as a mistake that
> can be fixed.

That may be a mistake, but it ended up being a standard.

> > Moving it means
> > rebuilding all the packages.
> 
> We do not want that.

If you change the program interpreter path, you have no other choice.


> > Could you please explain it how it works and what would be the use case?
> 
> I will explain the workings later, but let us discuss the use case. This
> scenario has been running since 2010. Why did I drop /lib64?
> 
> 1. A cleaner root directory.
> 2. A consistent root directory among architectures.
> 3. To avoid future architectures to have their own root directories,
>such as /libx32.

"Fixing" the x86-64 program interpreter path won't magically fix future
architecture. Also note that the /libx32/ld-linux-x32.so.2 path is also
defined in the same x86-64 ABI document.

> 4. Using /lib was the multiarch way.

I don't think you should use the past there. It was not at the time it
has been decided.

> 5. Specs, standards and laws can eventually be amended.

Why you don't start by that then? Just right a new ABI document for
the x86-64 CPU and create a new architecture from it. Then this
architecture can be supported by Debian.

> 6. Another challenge to accomplish something supposedly impossible.

That still do not explain how moving the program interpreter would work.

> It is all about transitions. You may think this use case is not worth
> the interim compatibility measures, but it is my use case and I have
> seen other people dislike /lib64. So, is this case worth a build profile
> at least?

No it clearly doesn't work the extra work of maintaining such a build
profile. In addition it will causes confusion, violate the debian policy
and the build profile specification.

Aurelien

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


signature.asc
Description: PGP signature

Bug#888073: glibc: Support amd64 systems without /lib64

[Sven Joachim]

On 2018-01-24 21:05 +0100, Javier Serrano Polo wrote:

> El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure:
>> The dynamic linker path is part of the
>> x86-64 ABI and is present in all ELF executables.
>
> I am aware that the original specification has that quirk, but it was
> made without multiarch in mind. Would you choose /lib64 if you could
> decide? I would not. I think that if there is a will this can be fixed.
>
> Other architectures are easy to see. For instance, m68k and powerpc
> conflict with /lib/ld.so.1. amd64's interpreter does not conflict, but
> all interpreters should be under /lib. I see /lib64 as a mistake that
> can be fixed.

/lib64 is a mistake, but it cannot be fixed without rebuilding the
world.  Which is fine for operating systems like OpenBSD where there are
no third-party binaries, but not on Linux.

>> Moving it means
>> rebuilding all the packages.
>
> We do not want that.

Well, then you have to live with /lib64.

Cheers,
   Sven

Bug#888073: glibc: Support amd64 systems without /lib64

[Carlos O'Donell]

On Wed, Jan 24, 2018 at 9:26 AM, Aurelien Jarno  wrote:
> On 2018-01-24 17:08, Javier Serrano Polo wrote:
>> 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
>
> I am not convinced about that. The dynamic linker path is part of the
> x86-64 ABI and is present in all ELF executables. Moving it means
> rebuilding all the packages. It should probably be done using a
> different architecture than "amd64".
>
> Could you please explain it how it works and what would be the use case?

The dynamic loader cannot be moved, it is an ABI artifact, as you rightly state.

In Fedora we had the UsrMove project:
https://fedoraproject.org/wiki/Features/UsrMove

So there is a symlink from /lib64 to /usr/lib64, that's the best you can do IMO.

Cheers,
Carlos.

Bug#888073: glibc: Support amd64 systems without /lib64

[Aurelien Jarno]

On 2018-01-24 17:08, Javier Serrano Polo wrote:
> 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

I am not convinced about that. The dynamic linker path is part of the
x86-64 ABI and is present in all ELF executables. Moving it means
rebuilding all the packages. It should probably be done using a
different architecture than "amd64".

Could you please explain it how it works and what would be the use case?

> of /lib64 by default, could you allow this option with a build profile,
> e.g. nolib64?

I am not convinced we want to add extra complexity in our already
complex makefiles and maintainer scripts unless there is a real use case.
This tend to bitrot and break other parts of the code.

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


signature.asc
Description: PGP signature