possible bug with libstdc++ in gcc4.3 linked to /usr/lib/libgcc_s.1.dylib

[gnurser@…]

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

[mww@…]

this is an upstream bug (gcc 4.0, 4.1, 4.2 links as expected) -- as this is just a snapshot which is clearly marked as BETA, I will not go into fixing this but rather wait for upstream to fix this; (this bug is in 4.3-20080221, too)

[mww@…]

version 4.3-20080306 seems to have this fixed;