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 s
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
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
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
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 docume
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 ~
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 suggestio
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 a
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 requir
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
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
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
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
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 /lib
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
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 t
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
interpre
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; t
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
u
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 thin
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
yo
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, bu
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,
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.
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'
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/l
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 r
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
> >
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 compatibi
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 ap
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-co
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
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 specificatio
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 signatur
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
> m
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. W
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
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
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
Descri
39 matches
Mail list logo
