stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [PATCH] Library path fix
Date Mon, 06 Nov 2006 21:38:25 GMT
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:


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:
> 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
>     else
>     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

View raw message