Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <454FAB51.5010603@roguewave.com>
Date: Mon, 06 Nov 2006 14:38:25 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] Library path fix
References: <454BB782.9000500@roguewave.com> <454BD649.9010205@roguewave.com>
In-Reply-To: <454BD649.9010205@roguewave.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Since the Sun C++ user manual doesn't explain which variable
is set in a typical installation of the compiler I posted the
question below to the Sun Studio C++ forum to help us decide
how to proceed:
http://forum.sun.com/jive/thread.jspa?threadID=111021

Martin

Martin Sebor wrote:
> Andrew Black wrote:
> 
>> Greetings all.
>>
>> Attached is a patch that aims to fix a bug that manifests itself when 
>> running 64-bit builds on SPARC Solaris.  The issue that arises is that 
>> dynamic builds of this type use the LD_LIBRARY_PATH_64 variable to 
>> determine where to locate shared libraries, rather than the 
>> LD_LIBRARY_PATH variable used almost everywhere else.
> 
> 
> According to the Environment Variables section of the Sun ld man
> page: http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9jt?a=view
> the runtime loader does use LD_LIBRARY_PATH for both 32 and 64-bit
> libs, but only when the suffix version of the variable is not
> defined. I.e., the variable with the _64 suffix (or _32 for 32-bit
> executables) takes precedence over the general LD_LIBRARY_PATH. We
> appear to set both in our environment so the stdcxx infrastructure
> needs to use the width-specific variable. But in an environment
> where only LD_LIBRARY_PATH is set stdcxx should probably use it
> in favor of the specific variable, otherwise we might cause the
> loader to fail to find the libraries pointed to by the generic
> variable. Another alternative might be for us to set the suffixed
> variable to the concatenation of the generic one and our paths if
> it's not defined.
> 
> I.e., in shell, something like
> 
>     if [ -z $LD_LIBRARY_PATH_64 ]; then
>         LD_LIBRARY_PATH_64=$LIBDIR:$LD_LIBRARY_PATH
>     else
>         LD_LIBRARY_PATH_64=$LIBDIR:$LD_LIBRARY_PATH_64
>     fi
> 
> Also, I would like to suggest a different name for the variable.
> How about LDSOVAR? (It's a VARiable specific to LD.SO, the Shared
> Object LoaDer aka dynamic linker). It would go with LDSOFLAGS.
> 
> Martin