[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Succees on OSX 64-bit with development branch
From: |
Jarno Rajahalme |
Subject: |
Re: Succees on OSX 64-bit with development branch |
Date: |
Wed, 21 Apr 2010 14:18:17 -0700 |
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.