BBv1 shared libraries on Darwin

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

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.

Doug

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 @@
}
else
{
- 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"$(LIBPATH:T)" -L"$(STDLIBPATH:T)" "$(NEEDLIBS)" "$(NEEDLIBS)" 
-l$(FINDLIBS) \
+ -L"$(LIBPATH:T)" -L"$(STDLIBPATH:T)" "$(NEEDLIBS)" "$(NEEDLIBS)" 
-l$(FINDLIBS) -dynamiclib -install_name "$(<[1]:D=:S=.dylib)" \
&& \
rm -f "$(<[1]:S=.lo)"
}