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 [PATCH] RE: STDCXX-488
Date Tue, 18 Mar 2008 19:12:40 GMT
 
Either way, the following patch should be applied assuming there are no
issues with it.

--- etc/config/gcc.config.orig	2008-03-14 15:43:04.000000000 -0600
+++ etc/config/gcc.config	2008-03-18 12:54:12.000000000 -0600
@@ -97,8 +97,11 @@
     # no -shared option for GCC on Mac OS X (Darwin)
     LDSOFLAGS = -shared
 else
-    # -dynamiclib is needed when linking the library
-    LDSOFLAGS = -dynamiclib
+    # Flags needed when linking the library
+    LDSOFLAGS = -dynamiclib \
+-install_name $(BUILDDIR)/$(LIBNAME) \
+-compatibility_version 4 \
+-current_version $(LIBVER)
 endif

Brad.

> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com] 
> Sent: Tuesday, March 18, 2008 12:50 PM
> To: dev@stdcxx.apache.org
> Subject: RE: STDCXX-488
> 
>  
> 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.
> 
> 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.
> > >>>  
> > >>>
> > > 
> > 
> > 
> 

Mime
View raw message