Solaris/64: wrong sys_lib_search_path_spec (was: libtool-2.0 release)

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Thu, Feb 02, 2006 at 07:38:13PM CET:
> On Thu, 2 Feb 2006, Bob Friesenhahn wrote:
> >
> >I have also noticed some disturbing "leakage" of default compiler (GCC) 
> >path information into the build which causes -m64 to not work properly (at 
> >least under Solaris, but seems likely to impact other targets as well).  
> >This bug did not used to exist on the 2.0 branch. In my test case, the 
> >compiler is always run via a shell script wrapper (gcc-64) which always 
> >runs gcc with -m64 so I am not sure what libtool did to encourage gcc to 
> >undo the effect of that option.
> 
> In order to clarify this issue some more, the problem only happens 
> when linking a C++ library and occurs because while libtool does link 
> using the C++ compiler, it supplies the options '-shared -nostdlib' 
> and then proceeds to tell the compiler what it should already have 
> done by default except that it gets something wrong and passes the 
> path to the 32-bit version of libstdc++.so rather than the 64-bit 
> version the compiler would have used when given the -m64 option.  So I 
> think that it is wrong for libtool to be specifying -nostdlib 
> and that it would be more reliable to allow the compiler to find its 
> own crt objects and libraries.  The operation may be a vestige of when 
> C++ libraries were linked directly using ld, except that this problem 
> did not occur a year ago so it has somehow been added since then.

Nope, but thank you very much for both your patience and your work on
this issue.  AFAICS this is really Solaris specific: 
  gcc -m64 -print-search-dirs

will happily print the 32bit search directories, but not the names of
the `sparcv9' subdirectories.  This means we have to fix this snippet
of libtool.m4:

| if test "$withGCC" = yes; then
|   sys_lib_search_path_spec=`$CC -print-search-dirs | $GREP "^libraries:" | 
$SED -e "s/^libraries://" -e "s,=/,/,g"`
|   if $ECHO "$sys_lib_search_path_spec" | $GREP ';' >/dev/null ; then
|     # if the path contains ";" then we assume it to be the separator
|     # otherwise default to the standard path separator (i.e. ":") - it is
|     # assumed that no part of a normal pathname contains ";" but that should
|     # okay in the real world where ";" in dirpaths is itself problematic.
|     sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED -e 
's/;/ /g'`
|   else
|     sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED  -e 
"s/$PATH_SEPARATOR/ /g"`
|   fi
| else
|   sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
| fi

or add a Solaris specific addon to the system-specific stuff below.

Do you know if GCC will search _only_ $dir/sparcv9 in the list or first
all $dir/sparcv9 directories and then then above?

The fix should probably not change the directory name if it already ends
in sparcv9 -- GCC might fix this eventually.  I even vaguely remember
that this may be a reported bug; it would be nice if somebody could
report it otherwise.

And BTW, not passing `-lstdc++' won't work as that will kill dlopening.

Cheers,
Ralf