stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] Library path fix
Date Fri, 03 Nov 2006 23:52:41 GMT
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

Mime
View raw message