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

[Javier Serrano Polo]

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. It uses an "ugly solution" that
happens to be the only way for a regular user to override interpreters,
as far as I know.

> What does
> ldd ./true print?

linux-vdso.so.1 (0x7ffddd5a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8c935f4000)
/lib64/ld-linux-x86-64.so.2 => 
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (0x7f8c93b9a000)

smime.p7s
Description: S/MIME cryptographic signature

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

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

[Javier Serrano Polo]

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.

smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure:
> 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.

Someone thinks that was a serious reply, so...

I would like to write an ABI document for the x86-64 CPU and create a
new architecture from it. Obviously, this is not as simple as writing a
document in my computer or starting a repository on GitHub. Could you
explain what this creation process actually means?

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dc 31 de 01 de 2018 a les 13:51 +, Michael Matz va escriure:
> 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

You are trying to run an unsupported binary without following the
installation procedure on a system without compatibility mode. Let me
remind my counterexample:[2]

$ sudo dpkg -i hello-nolib64_0.1_amd64.deb
Selecting previously unselected package hello-nolib64.
(Reading database ... 55548 files and directories currently installed.)
Preparing to unpack .../hello-nolib64_0.1_amd64.deb ...
Unpacking hello-nolib64 (0.1) ...
Setting up hello-nolib64 (0.1) ...
$ hello-nolib64
Hello, world!

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

No, I am not forcing anyone to do anything.[3] I respect your users that
love the /lib64 directory and find /lib/ld-linux-x86-64.so.2 ugly.

--
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073#60
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888073#165


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

El dt 30 de 01 de 2018 a les 15:01 +, Michael Matz va escriure:
> we split the world (into those that do support it, as allowed, and those 
> that don't, as also allowed).

That is the point of giving an choice. My world is split into users that
support /lib64 binaries and those that do not; it is their choice.

> That must not happen.

That happened in 2010.

> Perhaps we still can do something about the x32 program interpreter 
> (currently defined to sit in /libx32/ld-linux-x32.so.2).

Fine.

> 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. Let us wait for your users to
complain about manually creating a symlink.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

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?


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net, m...@suse.de, j...@suse.cz, 
a...@suse.de

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? You are comparing a function-calling convention with a
filesystem requirement. There is an interest in dropping /lib64 and
maintain interoperability, and I find it legitimate.

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

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

That happens with any standard. A system can be POSIX.1-2001 compliant
and not POSIX.1-2008 compliant; it does not support the new features. An
AMD64 system that does not evolve can always claim to be compatible with
version 0.99.7.

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

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

Sorry for not CCing. You missed the bits about custom loaders and
DT_NEEDED.

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

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.

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


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

For the record, I have decided to make easier to support binaries
depending on lib64 directories. Also, I will provide a package that
handles lib64 links for users that prefer a filesystem-based
implementation; initially, there will be only the /lib64 interpreter.

Debian could offer libc6 free from /lib64, even by default, but Debian's
position looks firm: users are not allowed to have systems
without /lib64 even if there are no compatibility issues. A wontfix tag
would be coherent with this decision.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El ds 27 de 01 de 2018 a les 17:06 +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?

I expect to find this functionality in the ELF loader. Where do you
expect it to be found?

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

That is your point of view. To me, implementation details are hidden
from the interface. To know the implementation details, you must know
the specific implementation, which is available to the user.

"Invoke this interpreter" and "load this dependency" may not be the same
as "read this file" or "test this file's existence"; it is a user
decision. The latter operations will act as you expect, unless the user
chooses otherwise, because of interoperability or whatever reason.

> Period, no point answering me again.

Why? We are exchanging interesting ideas. I learn about Debian's
shortcomings and my own ones.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

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? It is not a generic file load.

> "path name" means on the usual filesystem, just like in the rest of the
> document.

Let us see another example of path names: DT_NEEDED. Again, this is just
an interface. If a program declares a dependency on "/lib64/libc.so.6",
I may choose a suitable alternative. Does Debian support this case?

We have different interpretations about the interface. Mine results in
more interoperability and control for the user.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

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.

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

> You can't always adapt tools.

As one of my users, could you give me a real example of such tool?

On the another hand, Debian does not follow specifications where it is
inconvenient. Does Debian support any AMD64 loaders that search
libraries only under lib64 subdirectories?

--
[1] http://www.sco.com/developers/gabi/latest/ch5.pheader.html


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El ds 27 de 01 de 2018 a les 03:17 +0100, Samuel Thibault va escriure:
> So you are hiding some things.

I do not understand. What do you think I am hiding? There are no hidden
symlinks. The file /lib64/ld-linux-x86-64.so.2 does not exist, unless
you create it.

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

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


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El dv 26 de 01 de 2018 a les 22:27 +0100, Aurelien Jarno va escriure:
> It's an ugly solution and clearly not
> something we want to support, even as a build profile.

We have different views about what is ugly. Anyway, it is a maintainer's
choice, no problem. A wontfix tag would be appreciated.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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

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.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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 19:18 +0100, Samuel Thibault va escriure:
> Count a sixth person :)

You are welcome.

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

But this has nothing to do with the interpreter. Of course, I could run
a sid chroot, but this is not the point. When I finish my upgrade
process (which may take months), I will try again your test.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

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.

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?


hello-nolib64_0.1_amd64.deb
Description: application/deb


hello-nolib64_0.1.tar.gz
Description: application/compressed-tar
Format: 3.0 (native)
Source: hello-nolib64
Binary: hello-nolib64
Architecture: any
Version: 0.1
Maintainer: Javier Serrano Polo 
Standards-Version: 3.9.1
Build-Depends: debhelper (>= 8)
Checksums-Sha1: 
 0cb0a6e9395ddfd9eec0694c27925a43815a2a97 9730 hello-nolib64_0.1.tar.gz
Checksums-Sha256: 
 78b16e6c70c246a71842c5d2fb2d6ce0b963f5fa7bb1ffe28b09834758013a5e 9730 
hello-nolib64_0.1.tar.gz
Files: 
 c001d3d99923344e11598a991ed878e5 9730 hello-nolib64_0.1.tar.gz


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

El dc 24 de 01 de 2018 a les 23:18 +0100, Aurelien Jarno va escriure:
> If you change the program interpreter path, you have no other choice.

If you say so...

El dc 24 de 01 de 2018 a les 22:29 +, Adam Conrad va escriure:
> you won't be ABI-compatible with the rest
> of the Linux world,

I can run those programs without recompiling.

> If you want to patch your local system and rebuild it all to
> avoid that, go nuts.

I only rebuild the necessary packages.

> As
> a Debian bug, however, even a wishlist one, this should be a wontfix.

As you wish. You do not want to support amd64 systems without /lib64. It
is your choice to live with a /lib64 directory.


smime.p7s
Description: S/MIME cryptographic signature

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

[Javier Serrano Polo]

X-Debbugs-CC: cl...@debian.org, adcon...@0c3.net

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.


smime.p7s
Description: S/MIME cryptographic 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

[Javier Serrano Polo]

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.

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.

> Moving it means
> rebuilding all the packages.

We do not want that.

> 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.
4. Using /lib was the multiarch way.
5. Specs, standards and laws can eventually be amended.
6. Another challenge to accomplish something supposedly impossible.

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?


smime.p7s
Description: S/MIME cryptographic signature

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

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

[Javier Serrano Polo]

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?


smime.p7s
Description: S/MIME cryptographic signature