#14401: possible bug with libstdc++ in gcc4.3 linked to /usr/lib/libgcc_s.1.dylib ------------------------------------+--------------------------------------- Reporter: gnurser@googlemail.com | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Keywords: c++ gcc43 | ------------------------------------+--------------------------------------- I compiled python/numpy/scipy with gcc4.3 20080208 scipy failed one of the nose tests -- it gave a segmentation fault trying to call ext_module_with_include -- a shared library constructed with c++ and headers Now % otool -L ext_module_with_include.so gives ext_module_with_include.so: /opt/local/lib/gcc43/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.10.0) /opt/local/lib/gcc43/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) However % otool -L /opt/local/lib/gcc43/libstdc++.6.dylib gives: /opt/local/lib/gcc43/libstdc++.6.dylib: /opt/local/lib/gcc43/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) So /opt/local/lib/gcc43/libstdc++.6.dylib is linked to the old, system /usr/lib/libgcc_s.1.dylib instead of to the new /opt/local/lib/gcc43/libgcc_s.1.dylib The resulting conflict of libgcc_s.1.dylib libraries might explain the segmenting of the python module ext_module_with_include.so So, is this linkage of /opt/local/lib/gcc43/libstdc++.6.dylib to /usr/lib/libgcc_s.1.dylib a)perfectly Ok and irrelevant to my problem or b) a bug in the MacPorts portfile or c) a bug in gcc4.3 itself? The link to /usr/lib/libgcc_s.1.dylib is still there in gcc4.3 20080215 -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/14401> MacPorts </projects/macports> Ports system for Mac OS