How about the workaround that Andrew suggested: defining
DYLD_LIBRARY_PATH in the makefile?
Martin
Eric Lemings wrote:
After reproducing and observing the problem for this issue yesterday
afternoon, I thought the fix would be a simple matter of adding an
-rpath option to the link flags as Andrew suggested.
Naturally though, it's not that simple.
Basically, -rpath does not work on Mac OS X like it does on most other
Unix platforms. This is because the library path is actually embeded in
the dynamic library rather than executables via the -install_name link
flag. Furthermore, the MacOS X dynamic loader assumes that dynamic
libraries are installed in the customary directories (e.g. /usr/lib,
/usr/local/lib, current working directory) or find them using customary
environment variables. Does the current STDCXX build process even
contain an install stage (e.g `make install`)?
Most of the gory details are contained in the following reference guide:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/Dynam
icLibraries/Introduction.html
I also took a look at how dynamic libraries and executables are linked
in other distributions on MacOS X such as the Apache Portable Runtime.
It's written in C but the link process and flags are practically the
same.
All in all, this issue is going to take a little longer to resolve than
originally planned. In fact, I'm not sure we shouldn't just postpone
this issue until I complete the GNU Autotools [sup]port since all
linking (and installation) is already handled by GNU Libtool, even on
MacOS X.
Brad.
-----Original Message-----
From: Andrew Black [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 8:29 AM
To: [email protected]
Subject: Re: STDCXX-488
The failure currently observed is an inability to load the libstd
library in dynamic builds. When the RPATH makefile variable was
introduced, it was decided that it was a cleaner way to provide the
executables with a location for the library than the
alternative. That
alternative is to have some complex logic to determine
whether the path
should be prepended to LD_LIBRARY_PATH, LD_LIBRARY_PATH_64, SHLIBPATH,
DYLDPATH, or some other platform-dependent environment variable.
--Andrew Black
Eric Lemings wrote:
Could someone give an example of the failures described by
this issue?
In particular, I'm not sure the path should be embedded in the
executables and the Makefiles should invoke the executables with the
appropriate runtime library search paths.
Thanks,
Brad.
