octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Succees on OSX 64-bit with development branch


From: Ben Abbott
Subject: Re: Succees on OSX 64-bit with development branch
Date: Wed, 21 Apr 2010 20:08:07 -0400

On Apr 21, 2010, at 5:18 PM, Jarno Rajahalme wrote:

> 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.
> 
> 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

Jarno, did you build all dependencies with the same version of the gcc compiler 
and link to Apple's frameworks, or did you mix versions of gcc when building 
dependencies?

Also, were any of the dependencies built under Leopard (10.5), or did you 
rebuild all of them using Snow Leopard (10.6)?

Ben

p.s. notice I've switch to bottom posting so that late comers can follow along 
more easily.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]