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.