[PATCH] ld/Linux: determine program name in a more reliable manner

[Jan Beulich]

On 28.11.2025 10:55, Collin Funk wrote:
> Jan Beulich <jbeulich@suse.com> writes:
> 
>> What argv[0] holds can be pretty arbitrary. As long as it's used for just
>> diagnostics, that may be pretty okay to go from, but ld also uses it to
>> find linker scripts. For that we want to be sure we start from the real
>> executable name. Which on Linux we can determine from the /proc/self/exe
>> symbolic link target (provided of course procfs is mounted).
>>
>> While there constify program_name as well.
>> ---
>> Question is whether we should split program_name: Continue using argv[0]
>> for diagnostics (invokees may deliberately use more readable names there),
>> while using the /proc/self/exe target only for passing to
>> make_relative_prefix().
>>
>> Further, to become independent of the ldscripts symlink placed (too late,
>> see PR ld/33629) in .libs when --enable-shared is in use, should we check
>> for .libs as the last path component, i.e. retry invoking
>> make_relative_prefix() with that path component removed?
> 
> FWIW, my preference is using the last component of argv[0] for
> diagnostics.

That's an option, but can result in ambiguities in case you have multiple
programs of the same name in different directories.

> That is what we do in coreutils:
> 
>     $ mkdir -p a && ln -s /bin/ls a/gls
>     $ ./a/gls b
>     gls: cannot access 'b': No such file or directory
> 
> Otherwise the diagnostics don't match the name of the program if
> --program-suffix or similar are used when configuring.

Why would --program-suffix have an effect? Properly populating argv[0] is
the responsibility of the shell or whatever else looks up the actual
executable file.

Jan