Created attachment 518520 [details] emerge --info 1. Install system with current stable gcc-6.4.0 as system gcc, with packages using mesa 2. Install gcc-7.3.0 3. Leave gcc-6.4.0 as system gcc 4. Packages using mesa (and transitively libgcc_s.so) try to load libgcc_s.so from gcc-7.3.0, which causes them to fail (examples: firefox, chrome) I don't know, if the problem lies in using libgcc_s.so from a different gcc (shouldn't be a problem I guess, otherwise how could one upgrade gcc), gcc-7.3.0 being still buggy and producing incompatible libgcc_s.so (there's a comment in /usr/bin/gcc-config which suggests compatibility is expected from newer compilers), something going wrong in mesa/dri compilation, or me mixing up something. # gcc-config -l [1] x86_64-pc-linux-gnu-6.4.0 * [2] x86_64-pc-linux-gnu-7.3.0 # gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-6.4.0 ... [ ok ] # ldconfig # glxgears libGL error: unable to load driver: nouveau_dri.so libGL error: driver pointer missing libGL error: failed to load driver: nouveau Segmentation fault # ldd /usr/lib/dri/nouveau_dri.so|grep libgcc libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 (0x00007fcfaf020000) # more /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0 /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0 # vi /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf # more /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0 # ldconfig # glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. # ldd /usr/lib/dri/nouveau_dri.so | grep libgcc libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 (0x00007f9aff811000) #
Guys on IRS said it's a know issue, but anyway, I'll just add it here. For some reason libgcc_s.so.1 from gcc-7 is used automagically. gcc-config have gcc6 selected, profile is sourced, both gcc-6 and gcc-7 installed. reaper ~ # ldd /usr/bin/exa linux-vdso.so.1 (0x00007ffc9054d000) libz.so.1 => /lib64/libz.so.1 (0x00007fcfa1ace000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fcfa18ca000) librt.so.1 => /lib64/librt.so.1 (0x00007fcfa16c2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcfa14a3000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libgcc_s.so.1 (0x00007fcfa128c000) <<<< this one. libc.so.6 => /lib64/libc.so.6 (0x00007fcfa0ee1000) /lib64/ld-linux-x86-64.so.2 (0x00007fcfa1ce5000) after removing gcc-7 ldd /usr/bin/exa linux-vdso.so.1 (0x00007ffdbf7ea000) libz.so.1 => /lib64/libz.so.1 (0x00007fd17bd60000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd17bb5c000) librt.so.1 => /lib64/librt.so.1 (0x00007fd17b954000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd17b735000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/libgcc_s.so.1 (0x00007fd17b51f000) <<<<< now it points to gcc6. libc.so.6 => /lib64/libc.so.6 (0x00007fd17b174000) /lib64/ld-linux-x86-64.so.2 (0x00007fd17bf77000) Currently I have a binpkg of gcc-7 for building retpoline kernels, which I install for kernel or module compilation and unmerge right after.
If there's something for x11@ to do, please let me know and re'Cc us.
Is it still a problem? I'll need more details to understand the failure mode. The failure could happen in theory if libgcc_s.so of both gcc versions be loaded in RAM. Use of libgcc_s.so.1 from most recent gcc installed is supposed to work (there should be no ABI breakage). If you still have crashes posting backtrace might help: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
As I no longer have any systems created with gcc-6, I am no longer in the position to reproduce the problem.
