Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <47E01F4B.6070406@roguewave.com>
Date: Tue, 18 Mar 2008 14:00:11 -0600
From: Andrew Black <ablack@roguewave.com>
User-Agent: Thunderbird 1.5.0.14 (X11/20060911)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: STDCXX-488
References: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A364C@exchmail01.Blue.Roguewave.Com>
 <47DA8BA7.5020109@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3664@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3664@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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