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
