Currently gcc-config has a big bug which prevents it from copy libgcc_s.so libraries from the compiler's libraries' directory into /lib, making a system with binaries compiled with mixed version of GCC fail. The problem is that when it looks to copy the files, it uses the LDPATH variable found on /etc/env.d/gcc/ configuration file, which, on multilib systems, it's not a single path but a list of paths splitted by ':' chars (as usual for lists on unix vars). The result is that the libgcc_s.so files aren't copied at all and they make the system break when it's built with mixed version of gcc. The attached patch makes gcc-config discard every path but the first one, removing all the rest of the string after the first : char. After this is done, gcc-config can find libgcc_s.so files and copy them as needed. Regards, Diego
Created attachment 60960 [details, diff] Patch to make gcc-config discard all the multilib paths
is this bug already fixed?
I dont know why it should copy it in the first place, as all versions of gcc's LDPATH should be in /etc/ld.so.conf ...
it needs to copy it because some systems link binaries against libgcc_s.so.1 which are installed in / this first came up on arm and happens sometimes on ia64/amd64 ...
Not an issue with --as-needed it seems :/
--as-needed def improves the situation but it isnt fool proof ... that's why we should def make sure that libgcc_s.so.1 makes in into /
PITA either way, especially if you migth be using diff versions of gcc that might have slight abi changes without a major version change on the library.
Please note that gcc-config should not copy libgcc_s.so.1 to /lib but symlink it, otherwise prelink will fail miserably, see this thread: http://forums.gentoo.org/viewtopic-t-292379-highlight-prelink+gccconfig.html
Just symlinking it will break if binaries on /bin are linked against it.
fixed in gcc-config-1.3.13, thanks for the patch
