[Bug target/104707] New: gcc on riscv64 isn't passing entire library path to the linker

[Bug target/104707] New: gcc on riscv64 isn't passing entire library path to the linker

[sterprim at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

            Bug ID: 104707
           Summary: gcc on riscv64 isn't passing entire library path to
                    the linker
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sterprim at outlook dot com
  Target Milestone: ---

I tried to build mold linker (v1.1) for Arch Linux RISC-V, but gcc (11.2.0,
riscv64) filters out essential library paths (/lib and /usr/lib) and mold does
not have the notion of "default search paths" by design. Therefore, mold would
complain something like "mold: library not found: gcc_s" if extra
"-Wl,-L/lib,-L/usr/lib" is not added. Similarly lld fails to work with gcc,
complaining "library not found". But I found that bfd works well with gcc.

Output from gcc when compiling c source files:

$ echo 'int main() { return 0; }' > b.c
$ mold -run gcc -o exe b.c --verbose
  ......
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 30030405e2f045a69ffd93f3ffd2fa18
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe-'
 as -v --traditional-format -fpic -march=rv64imafdc -march=rv64imafdc
-mabi=lp64d -o /tmp/ccB31rEk.o /tmp/ccTd7vTJ.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe.'
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/collect2 -plugin
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccD5XkR9.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -melf64lriscv -dynamic-linker
/lib/ld-linux-riscv64-lp64d.so.1 -pie -o exe /lib/Scrt1.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crti.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtbeginS.o
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0 /tmp/ccB31rEk.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtendS.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtn.o
mold: library not found: gcc_s

Another test, but with -L/lib and -L/usr/lib added:

$ mold -run gcc -o exe b.c --verbose -Wl,-L/lib,-L/usr/lib
  ......
GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 30030405e2f045a69ffd93f3ffd2fa18
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe-'
 as -v --traditional-format -fpic -march=rv64imafdc -march=rv64imafdc
-mabi=lp64d -o /tmp/ccwQuF3N.o /tmp/cc4kmqtA.s
GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/:/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/usr/lib/gcc/riscv64-unknown-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe.'
 /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/collect2 -plugin
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccyg2R0b.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -melf64lriscv -dynamic-linker
/lib/ld-linux-riscv64-lp64d.so.1 -pie -o exe /lib/Scrt1.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crti.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtbeginS.o
-L/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0 /tmp/ccwQuF3N.o -L/lib
-L/usr/lib -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc
--push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtendS.o
/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/crtn.o
COLLECT_GCC_OPTIONS='-o' 'exe' '-v' '-march=rv64imafdc' '-mabi=lp64d'
'-march=rv64imafdc' '-dumpdir' 'exe.'

Log above shows that "/lib/:/usr/lib/" in LIBRARY_PATH seem to be filtered out
by default, but bfd has its own workaround for this issue. This situation
doesn't happen on x86-64 machines.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |riscv64-unknown-linux-gnu

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is a multilib issue with riscv and there might be another bug
already for this.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rui314 at gmail dot com

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 104708 has been marked as a duplicate of this bug. ***

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[jpalus+gcc at fastmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #3 from Jan Palus <jpalus+gcc at fastmail dot com> ---
I doubt this has anything to do with riscv or multilib. It's just gcc that
assumes all linkers should lookup /lib and /usr/lib and skips them when passing
library paths to linker:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931

I had the same issue on arm (32-bit) so no riscv, no multilib and dropping this
logic fixes the issue.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jan Palus from comment #3)
> I doubt this has anything to do with riscv or multilib. It's just gcc that
> assumes all linkers should lookup /lib and /usr/lib and skips them when
> passing library paths to linker:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;
> h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931
> 
> I had the same issue on arm (32-bit) so no riscv, no multilib and dropping
> this logic fixes the issue.

Arm linux multilib is just as complex as riscvs really.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[jpalus+gcc at fastmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #5 from Jan Palus <jpalus+gcc at fastmail dot com> ---
> Arm linux multilib is just as complex as riscvs really.

Perhaps my understanding of multilib is wrong but I meant pure 32bit, single
arch environment.

[Bug other/104707] GCC doesn't give default lib path to the linker when multilib is off

[sterprim at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Tan xc <sterprim at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |other
            Version|11.2.0                      |12.2.0
            Summary|gcc on riscv64 isn't        |GCC doesn't give default
                   |passing entire library path |lib path to the linker when
                   |to the linker               |multilib is off
             Target|riscv64-unknown-linux-gnu   |

--- Comment #6 from Tan xc <sterprim at outlook dot com> ---
This has been a lingering issue since the old days. GCC deliberately dismisses
well-known library paths when invoking the linker. When multilib is on, the %D
specifier in the spec automagically inserts library path from multilib option,
which conceals this problem.

While this logic saves a little parameter size, there is no need to keep saving
the space of the parameters, since all modern operating systems have a large
enough parameter space (all of them have 262k at least). This prevents GCC from
working with other linkers correctly.

[Bug other/104707] GCC doesn't give default lib path to the linker when multilib is off

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> since all modern operating systems have a large enough parameter space (all of them have 262k at least).

Windows still does not ....

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

[i at rvalue dot moe]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

rvalue <i at rvalue dot moe> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at rvalue dot moe

--- Comment #8 from rvalue <i at rvalue dot moe> ---
(In reply to Andrew Pinski from comment #7)
> > since all modern operating systems have a large enough parameter space (all of them have 262k at least).
> 
> Windows still does not ....

I don't think this code will make anything better or worse in Windows since it
simply compares the path with "/lib/" and "/usr/lib/", which never exist in
Windows.

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to rvalue from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > > since all modern operating systems have a large enough parameter space (all of them have 262k at least).
> > 
> > Windows still does not ....
> 
> I don't think this code will make anything better or worse in Windows since
> it simply compares the path with "/lib/" and "/usr/lib/", which never exist
> in Windows.

Cross compilers ...

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note multilib is not the issue. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304#c14 for more analysis of the
issue (I think there might be another bug report talking about this too).

[Bug driver/104707] GCC doesn't give default lib path to the linker when multilib is off

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2024-04-16

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Testing removal of this part from the driver.