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.
-- -- 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk