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

[Collin Funk]

Jan Beulich <jbeulich@suse.com> writes:

> 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.

True.

>> 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.

My bad. I was considering the separate case where you just use the
string "ld" instead of argv[0] or similar.

Collin