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:[EMAIL PROTECTED]
> Sent: Tuesday, March 18, 2008 12:50 PM
> To: [email protected]
> 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:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> > Sent: Tuesday, March 18, 2008 12:16 PM
> > To: [email protected]
> > 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:[EMAIL PROTECTED]
> > >> Sent: Friday, March 14, 2008 8:29 AM
> > >> To: [email protected]
> > >> 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.
> > >>>
> > >>>
> > >
> >
> >
>
