This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] elf: Always set l in _dl_init_paths (Bug 23462).


On 10/16/19 9:31 AM, Carlos O'Donell wrote:
> On 10/16/19 7:23 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>>> Does this change enable DT_RUNPATH/DT_RPATH for statically linked
>>>> binaries?  Should that receive a NEWS entry and a test?
>>>
>>> It does enable DT_RUNPATH/DT_RPATH for statically linked binaries,
>>> and we should probably add a test for that?
>>
>> Right.
> 
> Perfect, let me do that. I'll add another test.

This does not turn out to be true. And it makes sense when I think
about it more thoroughly.

The static executable, lacking a .dynamic section, does not fill in
any of the link maps's l_info data, in fact it's all just a list of
NULLs because there was no data to load.

Any subsequently loaded DSO will have such things, but they are already
handled by the DSO loading code.

You would have to assemble a static binary with a .dynamic section
and the static linker doesn't want to do that.

Therefore it's not a new feature.

We would have to add a LD_RUNPATH or LD_RPATH to feed this data into
the binary via an environment variable.

>>> If you think the semantic change here is wrong, please call that out.
>>
>> No, I think it would be a useful feature.  I sort-of ran into this here:
>>
>>   resolv/tst-idna_name_classify: Isolate from system libraries
>>   <https://sourceware.org/ml/libc-alpha/2019-10/msg00338.html>
>>
>> And I briefly wondered if we should do this automatically for
>> --enable-hardcoded-path-in-tests.

Given the above, do you think the original patch is good as-is?

Did I miss something else?

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]