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:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Tuesday, March 18, 2008 12:16 PM
>> To: dev@stdcxx.apache.org
>> 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:ablack@roguewave.com]
>>>> Sent: Friday, March 14, 2008 8:29 AM
>>>> To: dev@stdcxx.apache.org
>>>> 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.
>>>>>
>>>>>
>>
>
|