This is a summary of the libgcc_s error many people have reported. "ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found" Using this test program sum.f90 provided by groot@kde.org see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 We can demonstrate the fault. ! sum.f90 ! Performs summations using in a loop using EXIT statement ! Saves input information and the summation in a data file program summation implicit none integer :: sum, a print*, "This program performs summations. Enter 0 to stop." open(unit=10, file="SumData.DAT") sum = 0 do print*, "Add:" read*, a if (a == 0) then exit else sum = sum + a end if write(10,*) a end do print*, "Summation =", sum write(10,*) "Summation =", sum close(10) end gfortran -o sum sum.f90 ldd sum sum: libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x800822000) libm.so.5 => /lib/libm.so.5 (0x800b36000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d60000) libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x800f6e000) libc.so.7 => /lib/libc.so.7 (0x8011a3000) On FreeBSD 9.3 This is responsible for the plethora of bugs such as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210199 " When I attempt to launch the game I get the following back trace: Traceback (most recent call last): File "/usr/local/bin/FretsOnFire", line 16, in execfile(os.path.join(package_dir, "FretsOnFire.py")) File "/usr/local/lib/fretsonfire/FretsOnFire/FretsOnFire.py", line 45, in from GameEngine import GameEngine File "/usr/local/lib/fretsonfire/FretsOnFire/GameEngine.py", line 34, in from Data import Data File "/usr/local/lib/fretsonfire/FretsOnFire/Data.py", line 23, in from Font import Font File "/usr/local/lib/fretsonfire/FretsOnFire/Font.py", line 24, in import numpy File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line 180, in from . import add_newdocs File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/usr/local/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/usr/local/lib/python2.7/site-packages/numpy/core/__init__.py", line 14, in from . import multiarray ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found " Using the test program I can duplicate this bug: ./sum /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found But on HEAD ldd sum sum: libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x800822000) libm.so.5 => /lib/libm.so.5 (0x800b36000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d60000) libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x800f6e000) libc.so.7 => /lib/libc.so.7 (0x8011a3000) ./sum This program performs summations. Enter 0 to stop. Add: ... Works fine! What has changed? on HEAD strings /usr/local/lib/gcc46/libgfortran.so.3 |grep GCC on FreeBSD 9.3 strings /usr/local/lib/gcc48/libgfortran.so.3 |grep GCC GCC_4.2.0 GCC_3.0 GCC_3.3 GCC_4.6.0 on FreeBSD 9.3 readelf -V /usr/local/lib/gcc48/libgfortran.so > libgfortran_9_3.txt Version symbols section '.gnu.version' contains 1450 entries: Addr: 0000000000012540 Offset: 0x012540 Link: 2 (.dynsym) ... {elided} see http://people.FreeBSD.org/~db/libgfortran_9_3.txt for full text ... Version definition section '.gnu.version_d' contains 10 entries: Addr: 0x0000000000013098 Offset: 0x013098 Link: 3 (.dynstr) 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libgfortran.so.3 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GFORTRAN_1.0 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GFORTRAN_1.1 0x0054: Parent 1: GFORTRAN_1.0 0x005c: Rev: 1 Flags: none Index: 4 Cnt: 2 Name: GFORTRAN_1.2 0x0078: Parent 1: GFORTRAN_1.1 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: GFORTRAN_1.3 0x009c: Parent 1: GFORTRAN_1.2 0x00a4: Rev: 1 Flags: none Index: 6 Cnt: 2 Name: GFORTRAN_1.4 0x00c0: Parent 1: GFORTRAN_1.3 0x00c8: Rev: 1 Flags: none Index: 7 Cnt: 2 Name: GFORTRAN_1.5 0x00e4: Parent 1: GFORTRAN_1.4 0x00ec: Rev: 1 Flags: none Index: 8 Cnt: 1 Name: F2C_1.0 0x0108: Rev: 1 Flags: none Index: 9 Cnt: 1 Name: GFORTRAN_C99_1.0 0x0124: Rev: 1 Flags: none Index: 10 Cnt: 2 Name: GFORTRAN_C99_1.1 0x0140: Parent 1: GFORTRAN_C99_1.0 Version needs section '.gnu.version_r' contains 4 entries: Addr: 0x00000000000131e0 Offset: 0x0131e0 Link to section: 3 (.dynstr) 000000: Version: 1 File: libquadmath.so.0 Cnt: 1 0x0010: Name: QUADMATH_1.0 Flags: none Version: 15 0x0020: Version: 1 File: libgcc_s.so.1 Cnt: 4 0x0030: Name: GCC_4.2.0 Flags: none Version: 18 0x0040: Name: GCC_3.0 Flags: none Version: 17 0x0050: Name: GCC_3.3 Flags: none Version: 14 0x0060: Name: GCC_4.6.0 Flags: none Version: 13 0x0070: Version: 1 File: libc.so.7 Cnt: 2 0x0080: Name: FBSD_1.3 Flags: none Version: 20 0x0090: Name: FBSD_1.0 Flags: none Version: 12 0x00a0: Version: 1 File: libm.so.5 Cnt: 3 0x00b0: Name: FBSD_1.2 Flags: none Version: 19 0x00c0: Name: FBSD_1.1 Flags: none Version: 16 0x00d0: Name: FBSD_1.0 Flags: none Version: 11 On HEAD readelf -V /usr/local/lib/gcc46/libgfortran.so> libgfortran_HEAD.txt Version symbol section (.gnu.version): 000: 0 *local* 0 *local* 2 GFORTRAN_1.0 2 GFORTRAN_1.0 {elided} See http://people.FreeBSD.org/~db/libgfortran_HEAD.txt for full text On HEAD sections '.gnu.version_r' and '.gnu.version_d' are missing entirely. (why?) Thus rtld does not reject our version of libgcc as being too old and will run without flagging an error. However: 1) we should never have our base libgcc_s linked in when using gcc from ports or gfortran. We should always be having a RPATH to /usr/local/lib/gcc${VER} where VER is the version of gcc / gfortran we used. 46 47 48 etc. 2) If we do link in our base libgcc_s it should still work, even though that is wrong. Anything linked with gcc (gcc compiler or gfortran) must have an rpath to /usr/local/lib/gcc${VER} e.g. looking at Uses/fortran FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \ -L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin Bur our Uses/compiler for C does not have the -Wl,-rpath stanza added in CFLAGS, CXXFLAGS or LDFLAGS Next cmake. Our cmake does not pass along the right invocation to keep the rpath information. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 Summary: The appropriate RPATH is in the compiled .so and binaries when it is built but is stripped out as it is finally installed. Thus anything linked with our cmake can run into this bug as well. Simple fix to compiler.mk Index: compiler.mk =================================================================== --- compiler.mk (revision 416615) +++ compiler.mk (working copy) @@ -248,3 +248,7 @@ .endif .endif + +.if ${CHOSEN_COMPILER_TYPE == gcc } +CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}" +.endif I will phabricator this db_: I think the best is you put your patch in phabricator > bapt: I was thinking that. and cc peoples like tijl, gerald etc > bapt: yes. moreover, it's not just cmake that needs the -Wl > whenever gcc itself is used it should force an -Wl,rpath= hence cc gerald :) > not just gfortran like gerald has done > yeppers