stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: STDCXX-488
Date Tue, 18 Mar 2008 18:15:54 GMT
How about the workaround that Andrew suggested: defining
DYLD_LIBRARY_PATH in the makefile?


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:
> 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 [] 
>> Sent: Friday, March 14, 2008 8:29 AM
>> To:
>> 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.

View raw message