You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Eric Lemings <Er...@roguewave.com> on 2008/03/14 00:35:06 UTC
STDCXX-488
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.
RE: [PATCH] RE: STDCXX-488
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com]
> Sent: Tuesday, March 18, 2008 1:13 PM
> To: dev@stdcxx.apache.org
> Subject: [PATCH] RE: STDCXX-488
>
>
...
> +-install_name $(BUILDDIR)/$(LIBNAME) \
Oops #1. Should be:
-install_name $(BUILDDIR)/lib/$(LIBNAME) \
This [corrected] patch is all that's needed. With these link flags,
tests, examples, and other executables will run without the need for
environment variables (e.g. LD_LIBRARY_PATH, DYLD_LIBRARY_PATH).
Going to submit this patch and resolve the issue.
Brad.
[PATCH] RE: STDCXX-488
Posted by Eric Lemings <Er...@roguewave.com>.
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.
> > >>>
> > >>>
> > >
> >
> >
>
Re: STDCXX-488
Posted by Martin Sebor <se...@roguewave.com>.
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.
>>>>>
>>>>>
>>
>
RE: STDCXX-488
Posted by Eric Lemings <Er...@roguewave.com>.
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.
> >>>
> >>>
> >
>
>
Re: STDCXX-488
Posted by Martin Sebor <se...@roguewave.com>.
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/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.
>>>
>>>
>
Re: STDCXX-488
Posted by Andrew Black <ab...@roguewave.com>.
Greetings Brad
To answer a question you posed, there currently is an install target.
The target can be found in the top level GNUmakefile, near the end of
the file (line 709 in the version I'm looking at). This target in turn
invokes the install target in the lib and bin subdirectories of the
build tree. One of the options passed to the target is the PREFIX
variable, defining where the installation is to be performed to. The
other option which can be passed is LOCALES, defining the list of
locales to install.
--Andrew Black
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/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.
>>>
>>>
RE: STDCXX-488
Posted by Eric Lemings <Er...@roguewave.com>.
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.
> >
> >
>
Re: STDCXX-488
Posted by Andrew Black <ab...@roguewave.com>.
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.
>
>