Boost logo

Boost-Build :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2005-04-21 23:08:00

The way we're currently linking shared libraries libraries on Darwin
doesn't work all that well outside of the testing harness. The problem
is that when one links against a Darwin dylib with another dynamic
library (or a module/application bundle), the module stores the path to
the dylib and will only look for the dylib with that path... with bjam,
that path is something like
../../../../python/build/shared-linkable-true/blah/blah/, so if you
ever copy the module anywhere it cannot find the dylib.

The way to handle this in Darwin is to link the dylib with an "install
name", which is stored in the dylib and tells shared libraries/modules
that link against it where it will be found at run time. It's kind of
like an rpath, but weird and in the wrong place. If the dylib will
always be installed in some location (say /usr/lib), the install name
could be /usr/lib/libfoo.dylib and all would be well... but that
doesn't work in our testing harness because we don't install.

So, the real solution is to use the library name, e.g.,
libboost_python.dylib, as the install name. Then it will be found at
load time anywhere in the DYLD_LIBRARY_PATH. Since we already set this
properly before we run tests, everything works fine. And when we
install dylibs, they go someplace that should be in DYLD_LIBRARY_PATH

I've committed the following patch to darwin-tools.jam. When linking a
dylib, we use -dynamiclib and -installname to set the install name of
the dylib. I don't believe that we need the -Wl,-dynamic -nostartfiles
-Wl,-dylib -Wl,-ldylib1.o link options, so I've commented them out.
Actually, I'm not sure about -nostartfiles: does anyone know why we
have this?

I've run the Signals tests (linking against a libboost_signals.dylib,
of course) through bjam and all is well. Additionally, I can build the
BGL-Python bindings extension module, linked against the Boost.Python
dylib, copy both the dylib and the module to a different directory and
then use the extension module from Python. This step was broken before.

I'm also kicking off a complete regression test run on one of the OSL
Macs to be sure that this hasn't broken anything.

Comments would be appreciated, of course.


Index: darwin-tools.jam
RCS file: /cvsroot/boost/boost/tools/build/v1/darwin-tools.jam,v
retrieving revision 1.18
diff -u -r1.18 darwin-tools.jam
--- darwin-tools.jam 1 Sep 2004 05:37:03 -0000 1.18
+++ darwin-tools.jam 22 Apr 2005 02:36:46 -0000
@@ -134,8 +134,8 @@
- flags darwin LINKFLAGS <target-type>$(SHARED_TYPES) :
- -Wl,-dynamic -nostartfiles -Wl,-dylib -Wl,-ldylib1.o ;
+# flags darwin LINKFLAGS <target-type>$(SHARED_TYPES) :
+# -Wl,-dynamic -nostartfiles -Wl,-dylib -Wl,-ldylib1.o ;

flags darwin .LINKFLAGS <linkflags> ;
@@ -184,7 +184,7 @@
&& \
$(.GCC_BIN_DIR)$(.GXX) $(LINKFLAGS) -o "$(<[1])" "$(<[1]:S=.lo)" \
-F$(FRAMEWORKS:D) -framework$(_)$(FRAMEWORKS:D=) \
-l$(FINDLIBS) -dynamiclib -install_name "$(<[1]:D=:S=.dylib)" \
&& \
rm -f "$(<[1]:S=.lo)"


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at