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