>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 http://tinyurl.com/3p4385, 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 [http://tinyurl.com/3hxjjm]. 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
