Hello,
On Thu, 6 Apr 2023, Shiqi Zhang wrote:
> Currently, gcc delibrately filters out default library paths "/lib/" and
> "/usr/lib/", causing some linkers like mold fails to find libraries.
If linkers claim to be a compatible replacement for other linkers then
they certainly should behave in a similar way. In this case: look into
/lib and /usr/lib when something isn't found till then.
> This behavior was introduced at least 31 years ago in the initial
> revision of the git repo, personally I think it's obsolete because:
> 1. The less than 20 bytes of saving is negligible compares to the command
> line argument space of most hosts today.
That's not the issue that is solved by ignoring these paths in the driver
for %D/%I directives. The issue is (traditionally) that even if the
startfiles sit in /usr/lib (say), you don't want to add -L/usr/lib to the
linker command line because the user might have added -L/usr/local/lib
explicitely into her link command and depending on order of spec file
entries the -L/usr/lib would be added in front interacting with the
expectations of where libraries are found.
Hence: never add something in (essentially) random places that is default
fallback anyway. (Obviously the above problem could be solved in a
different, more complicated, way. But this is the way it was solved since
about forever).
If mold doesn't look into {,/usr}/lib{,64} (as appropriate) by default
then that's the problem of mold.
Ciao,
Michael.
