Hi Florian,
On Sat, Dec 04, 2021 at 01:59:14PM +0100, Florian Weimer wrote:
> It is as architecture-independent as ldconfig or getconf. Perhaps a bit
> more so than getconf.
Both of those are bad examples as both are lies. An amd64 ldconfig
really does not handle arm64 libraries at all. I'd
* Aurelien Jarno:
> Hi,
>
> On 2021-12-02 19:51, 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
>>
Hi,
On 2021-12-02 19:51, 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
* Helmut Grohne:
> Hi Florian,
>
> On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
>> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
>> mentioned below. I think this is the way to go. Some care will be
>> needed to avoid endless loops, but that should be
Hi Florian,
On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
> mentioned below. I think this is the way to go. Some care will be
> needed to avoid endless loops, but that should be it.
Can I ask you to go
On Fri, Dec 03, 2021 at 05:59:17PM +0100, Florian Weimer wrote:
> * Theodore Y. Ts'o:
>
> > * How does ld.so --preload *work*?
>
> The dynamic loader has an array of preloaded sonames, and it processes
> them before loading the dependencies of the main program. This way,
> definitions in the
On Fri, 03 Dec 2021 at 18:29:33 +0100, Florian Weimer wrote:
> > On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> >> If someone wants to upstream the multi-arch patches, that would be
> >> great.
> >
> > I think multiarch is mostly build-time configuration rather than patches.
>
>
On Fri, Dec 03, 2021 at 11:33:25AM -0500, Theodore Y. Ts'o wrote:
> Some stupid questions that I couldn't answer by reading the man page
> or doing a quick google search
> * How does ld.so --preload *work*?
ld.so is the ELF interpreter. If you run a normal binary, the kernel
rewrites this
* Simon McVittie:
> On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
>> Having ld.so as a real command makes the name architecture-agnostic.
>> This discourages from hard-coding non-portable paths such as
>> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>>
* Theodore Y. Ts'o:
> * How does ld.so --preload *work*?
The dynamic loader has an array of preloaded sonames, and it processes
them before loading the dependencies of the main program. This way,
definitions in the preloaded objects preempt definitions in the shared
objects.
> * Does it modify
On Thu, 02 Dec 2021 at 19:51:16 +0100, Florian Weimer wrote:
> Having ld.so as a real command makes the name architecture-agnostic.
> This discourages from hard-coding non-portable paths such as
> /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
>
On Fri, Dec 03, 2021 at 02:46:27PM +0100, Bastian Blank wrote:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> > Right, thanks for providing a concrete example. A (somewhat) portable
> > version would look like this:
> > ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0'
* Bastian Blank:
> On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
>> Right, thanks for providing a concrete example. A (somewhat) portable
>> version would look like this:
>> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
>
> You mean
> ld.so --preload
On Fri, Dec 03, 2021 at 01:57:08PM +0100, Florian Weimer wrote:
> Right, thanks for providing a concrete example. A (somewhat) portable
> version would look like this:
> ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl
You mean
ld.so --preload libeatmydata.so.1.3.0 /bin/ls
?
ld.so
* Paul Wise:
> Florian Weimer wrote:
>
>> I'd like to provide an ld.so command as part of glibc.
>
> Will this happen in glibc upstream or just in Debian?
Upstream, and then Debian. The symbolic link would likely and up in
libc-bin in Debian.
>> Today, ld.so can be used to activate preloading,
Florian Weimer wrote:
> I'd like to provide an ld.so command as part of glibc.
Will this happen in glibc upstream or just in Debian?
> 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
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
17 matches
Mail list logo
