The toolchain will dynamically link various binaries and libraries to libgcc_s.so.1 on ARM while it will statically link to libgcc_s.a on other architectures like amd64. This causes binaries in / to dynamically link to /usr, which breaks when fstab mounts /usr. I noticed because binaries and libraries in sys-fs/zfs are affected, but numerous other packages are affected. These can be discovered by running `grep -r libgcc_s.so.1 /bin /sbin`. I tried passing -static-libgcc as part of LDFLAGS at various points of the sys-fs/zfs build system, but GCC appears to ignore it entirely. I also tested a Hello World Program, but I was unable to reproduce this with it. It appears that not all binaries are affected. In particular, /bin/echo and various other binaries from coreutils appear to be unaffected. Dynamically linking to libgcc_s.so.1 has benefits, but it should be done consistently across all architectures and the library would need to be moved to / to prevent things from breaking.
on arches that lack, in hardware, support for more complicated math functions, they will often link against libgcc_s.so.1 for them. this is not a bug.
The documentation claims that passing -static-libgcc will make GCC link to the shared library, but GCC refuses to tell the linker statically link to libgcc under any circumstance. We do not have an explanation for this behavior. I have updated the title to be more descriptive of the issue.
Is this still an issue? Do you have minimal example with a function from libgcc?
