Eric Lemings wrote:
Possible, but I believe it would require substantial changes to the
<srcdir>/etc/config/makefile.rules file and any other file that
executes an example or test.
Maybe I don't understand the issue. I thought the problem was that
when running tests or examples linked against a shared lib via make
run the dynamic linker wouldn't be able to find the library because
it doesn't understand LD_LIBRARY_PATH (the solution we use on all
platforms that don't have rpath). So wouldn't the fix on Darwin be
just to replace LD_LIBRARY_PATH with DYLD_LIBRARY_PATH in makefile.
rules?
Martin
Brad.
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, March 18, 2008 12:16 PM
To: [email protected]
Subject: Re: STDCXX-488
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/Concep
tual/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.
