Re: [jamboost] BBv1 shared libraries on Darwin

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-21 23:34:00

Douglas Gregor wrote:
> The way we're currently linking shared libraries libraries on Darwin 
> doesn't work all that well outside of the testing harness.

Not surprised given that's the only context under which I tested it.

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

We do as of a few days ago :-)

> I've committed the following patch to darwin-tools.jam. 

Cool. Thanks for the ever expanding functionality.

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

OK. Well see.

> Actually, I'm not sure about -nostartfiles: does anyone know why we 
> have this?

When I wrote the darwin/gcc support it would give link errors if those 
startup functions got included. This was with the earlier compiler in 
10.1 (I think). So perhaps that aspect is fixed now. As in perhaps it 
now notices that it's not an application and includes the correct startup.

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

Awesome!

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org