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 http://tinyurl.com/3p4385, 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).
Martin
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
