[RFC PATCH] driver: unfilter default library path [PR 104707]

[RFC PATCH] driver: unfilter default library path [PR 104707]

[Shiqi Zhang]

Currently, gcc delibrately filters out default library paths "/lib/" and
"/usr/lib/", causing some linkers like mold fails to find libraries.

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.
 2. The driver program should provide adequate information for workers

There might be some hosts with such a small argv space that the 20-byte
saving really matters. If so, we can make this filter compiles conditionally in
these targets.

Related issue:
https://github.com/rui314/mold/issues/358

---
 gcc/gcc.cc | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 16bb07f2cdc..1beb23ba279 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -7904,17 +7904,6 @@ is_directory (const char *path1, bool linker)
   *cp++ = '.';
   *cp = '\0';
 
-  /* Exclude directories that the linker is known to search.  */
-  if (linker
-      && IS_DIR_SEPARATOR (path[0])
-      && ((cp - path == 6
-	   && filename_ncmp (path + 1, "lib", 3) == 0)
-	  || (cp - path == 10
-	      && filename_ncmp (path + 1, "usr", 3) == 0
-	      && IS_DIR_SEPARATOR (path[4])
-	      && filename_ncmp (path + 5, "lib", 3) == 0)))
-    return 0;
-
   return (stat (path, &st) >= 0 && S_ISDIR (st.st_mode));
 }
 
-- 
2.40.0

Re: [RFC PATCH] driver: unfilter default library path [PR 104707]

[Michael Matz]

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.