stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
Date Tue, 29 Apr 2008 18:09:58 GMT

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

I found some discussion on this flag was found on the boost list here
[]. Here is a snippet.

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

  has an "install_name" of "libA.dylib" 
  has an "install_name" of "/Users/Shared/Sandbox/lib/libB.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. 

Is this something that we want?


View raw message