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 19:07:25 GMT
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.


> Brad.
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Tuesday, March 18, 2008 12:16 PM
>> To:
>> 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:
>> 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 [] 
>>>> 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, 
>>>> 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