On Fr, 03.12.21 13:46, Florian Weimer (fwei...@redhat.com) wrote:
> We can likely add the official path to the dynamic linker as a macro in
> .
That would be lovely!
Lennart
--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedorapro
* Lennart Poettering:
> On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:
>
>> It would go into glibc-common on x86-64, and the initial version won't
>> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
>
> "the initial version"? That phrasing makes me wonder, what
* Kamil Dudka:
> On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
>> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
>> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
>> > > On 12/2/21 15:08, Sérgio Basto wrote:
>> > > > I didn't understood . What is the diffe
On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:
> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
"the initial version"? That phrasing makes me wonder, what longer term
plans do you have
On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> > > On 12/2/21 15:08, Sérgio Basto wrote:
> > > > I didn't understood . What is the difference for /lib64/ld-2.
On Thu, Dec 02, 2021 at 08:20:52PM +0100, Florian Weimer wrote:
> * Nico Kadel-Garcia:
>
> > On Thu, Dec 2, 2021 at 1:39 PM Florian Weimer wrote:
> >>
> >> I'd like to provide an ld.so command as part of glibc.
+1.
> > That seems a horrible idea. The ".so" suffix indicates that it is a
> > libr
On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
>
> > On 12/2/21 15:08, Sérgio Basto wrote:
> >
> > > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > > or
> > > /lib/ld-2.33.so ?
> >
> >
>
>
> rephr
On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> On 12/2/21 15:08, Sérgio Basto wrote:
> > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > or
> > /lib/ld-2.33.so ?
>
rephrasing my question :
What is the difference of /usr/bin/ld.so for /lib64/ld-2.33.so or
/lib/l
On 12/2/21 15:08, Sérgio Basto wrote:
I didn't understood . What is the difference for /lib64/ld-2.33.so or
/lib/ld-2.33.so ?
The lib64 one is 64-bit and the lib one is 32-bit.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
On Thu, 2021-12-02 at 19:38 +0100, Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc. Today, ld.so
> can
> be used to activate preloading, for example. Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocess
On Thursday, December 2, 2021 7:38:29 PM CET Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc. Today, ld.so can
> be used to activate preloading, for example. Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by su
* Nico Kadel-Garcia:
> On Thu, Dec 2, 2021 at 1:39 PM Florian Weimer wrote:
>>
>> I'd like to provide an ld.so command as part of glibc. Today, ld.so can
>> be used to activate preloading, for example. Compared to LD_PRELOAD,
>> the difference is that it's specific to one process, and won't be
On Thu, Dec 2, 2021 at 1:39 PM Florian Weimer wrote:
>
> I'd like to provide an ld.so command as part of glibc. Today, ld.so can
> be used to activate preloading, for example. Compared to LD_PRELOAD,
> the difference is that it's specific to one process, and won't be
> inherited by subprocesses—
I'd like to provide an ld.so command as part of glibc. Today, ld.so can
be used to activate preloading, for example. Compared to LD_PRELOAD,
the difference is that it's specific to one process, and won't be
inherited by subprocesses—something is that exactly what is needed.
There is also some use
14 matches
Mail list logo
