Re: Succees on OSX 64-bit with development branch

[Jarno Rajahalme]

Short recap: in OSX, system dylibs pull in the system version of the 
libstdc++.6.dylib. When using GCC > 4.2, the code needs to be linked with a 
newer libstdc++.6.dylib. Having two copies of the same dylib linked in causes 
some weird results, caused by one libstdc++ linking to another, which results 
in malloc/free errors, segmentation faults, aborts, etc.

The solution to this linking problem was quite easy, when found. All it takes 
is to have the newer libstdc++ (e.g. /opt/local/lib/gcc44/libstdc++.6.dylib) in 
the LDFLAGS. This way to cross-linkage between the different versions seems to 
go away, no seg faults, and all tests (but the one of the svds tests) succeed.

There is also a linking option -dylib_file, which, according to the man ld is 
intended for resolving a similar kind of a problem. However having "-dylib_file 
/usr/lib/libstdc++.6.dylib:/opt/local/lib/gcc44/libstdc++.6.dylib" in LDFLAGS 
did not help, there are still two versions of libstdc++.6.dylib linked in.

Finally, there is the linking option -flat_namespace, which reveals the 
duplicate libraries at the link time (warnings), but did not resolve the 
problem.

In the end, neither of these options is required.

  Jarno

On Apr 15, 2010, at 11:58 AM, ext Jarno Rajahalme wrote:

> The root of the problem seems to be the linkage from line 24 to 23: Why would 
> the gcc 4.4 libstdc++.6.dylib link to a streambuf function in the system 
> libstdc++, and not it's own copy of it?
> ...
> How it is possible that a call to a function within GCC 4.4 libstdc++ is 
> resolved at the load time, and to a different library (system's version of 
> the libstdc++)? Could the linking be somehow changed to have GCC 4.4 
> libstdc++ use it's own version of the function?
> 
> For some reason unknown to me, configuring with --without-framework-opengl 
> produces binaries where this problem does not arise (no seg fault), even when 
> there still are two different copies of libstdc++ within the binary images. 
> The system version of libstdc++ is pulled in by libGLU, which is linked in 
> regardless of the framework-opengl status.