[PATCH 01/28] elf: Do not search HWCAP subdirectories in statically linked binaries

[Carlos O'Donell]

On 10/1/20 2:29 PM, Adhemerval Zanella wrote:
> 
> 
> On 01/10/2020 15:24, Carlos O'Donell wrote:
>> On 10/1/20 2:22 PM, Adhemerval Zanella via Libc-alpha wrote:
>>>
>>>
>>> On 01/10/2020 13:31, Florian Weimer via Libc-alpha wrote:
>>>> This functionality does not seem to be useful since static dlopen
>>>> is mostly used for iconv/character set conversion and NSS support.
>>>> gconv modules are loaded with full paths anyway, so that the
>>>> HWCAP subdirectory logic does not apply.
>>>
>>> This change looks reasonable, although it makes the semantic of 
>>> statically linked programs slight different than dynamic one regarding
>>> dlopen.
>>
>> I think this is OK.
>>
>> dlopen from statically linked programs is deprecated, the only uses
>> should be internal to glibc in NSS And iconv.
>>
>> We really really want:
>>
>> * Just a statically linked program that has no external deps.
>>
>> * Just a dynamically linked program can support dlopen.
>>
>> This half-way inbetween support we have has serious consequences,
>> and is the reason I supported us deprecating dlopen from static
>> binaries. Users should not be allowed to shoot themselves in
>> the foot.
>>
>> $0.02.
>>
> 
> I agree, usually on discussion about static linking with glibc users
> get perplexed why shared libraries are being loaded under the hood
> and usually this is a deal breaker on most usercases (another one
> is the minimum kernel requirement).
 Fixing the dlopen case requires splitting the interface at the NSS
boundary (as Florian suggested?) and calling out from the static
binary to some kind of 'getent'-like binary, perhaps even getent
itself in compat cases.

The minimum kernel requirement is much easier to explain. We have
a minimum requirement. I find users get that when it's explained
clearly.

-- 
Cheers,
Carlos.