incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: STDCXX-488
Date Tue, 18 Mar 2008 15:48:43 GMT

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: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.
> >  
> > 
> 

Mime
View raw message