stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: ABI problem on Darwin
Date Wed, 30 Apr 2008 00:21:59 GMT
Travis Vitek wrote:
>> Eric Lemings wrote:
>> The workaround is to remove the link flags for version info (i.e.
>> -compatibility_version and -current_version) from the file
>> etc/config/gcc.config.  This takes care of the runtime link error.
> We should probably commit the fix to 4.2.x to get the ball rolling.
>> There are some other link flags that could/should probably be added
>> (e.g. -Wl,-undefined, -Wl,dynamic_lookup, -Wl,-single_module) but
>> that's a post-4.2.1 change.  I'd also to figure out why the version
>> info flags were working before now at some point.
> I looked at the patch, I'm thinking that we
> don't want the -install_name flag either.

We definitely don't want to be hardcoding BUILDDIR into the lib,
no matter what it does. BUILDDIR is a temporary directory that
most likely disappears as soon as the library's installed.

> If I understand what it does,
> it is different than the -rpath flag in that it is applied to the shared
> library itself and not the executables that link to it.

Right. Rpath is just a convenience for us so that we can easily
run programs without setting LD_LIBRARY_PATH.

> The install_name
> associated with the library tells the runtime linker where the library
> is allowed to be found, so once you've tagged a shared library with an
> install_name that is an absolute path that library can never be moved
> without modifying the install_name.

That could be used in the install target (or if the INSTALLDIR
variable is set).


> I found some discussion on this flag was found on the boost list here
> []. Here is a snippet.
> [quote]
>> And why does OSX embed the path? Standard GNU tools will only 
>> embed "soname" -- which is a name embedded in a shared library 
>> that tells by what name other libraries should refer to it. 
>> Is something like that present on OSX? 
> Right, this is called the "install_name" for dylibs. It can be a file   
> name or an entire path or some "special paths" like   
> "@executable_path/../". When one library links to another this   
> "install_name" is used so that all the libraries and executables know   
> how to find each other. An example should clarify this. 
> libA.dylib
>   has an "install_name" of "libA.dylib" 
> libB.dylib
>   has an "install_name" of "/Users/Shared/Sandbox/lib/libB.dylib" 
> libC.dylib
>   has an "install_name" of "@executable_path/../lib/libC.dylib" 
> Now we have an executable called foo that links against all three   
> libraries. In order for foo to run successfully, libA.dylib must be   
> in a folder defined in the DYLD_LIBRARY_PATH, libB must be located   
> in /Users/Shared/Sandbox/lib/ and libC must be located in a "../lib/"   
> which is a directory that is relative to foo. 
> That, in a nutshell is how OS X linking works. 
> [/quote]
> Is this something that we want?
> Travis

View raw message