LT 1.5: problem with Solaris Forte 64 bit shared C++ libraries

[Jeff Squyres]

As the subject suggests, I have found a specific corner case that libtoll
1.5 does not appear to handle correctly.

Short version
-------------

It appears that libtool is using the C++ compiler to link the final
shared library, but is dropping some necessary CXXFLAGS, which causes
an error.

Detailed version
----------------

I am attempting to build a 64 bit C++ shared library using the Solaris
Forte compilers, and libtool seems to do the Wrong Thing in the final
link step.  I have attached a sample package that shows the problem.

1. Testing was performed on Solaris 2.8 with the Sun Forte version 6
   (update 2) compilers.  /usr/ccs/bin appears in the path *before*
   /usr/ucb.

2. I am using autoconf 2.57, automake 1.7.3, and libtool 1.5.  All
   were configured/compiled/installed with:

   setenv CC cc
   setenv CXX CC
   setenv F77 f77
   ./configure --prefix=/my/directory
   make all install

   Then my PATH was prefixed with /my/directory/bin.

3. The sample project attached is a simple configure.ac, Makefile.am,
   and two dummy .cc files to create a C++ library.

4. Its configuration/build system were generated with the included
   [primitive] autogen.sh script, which essentially runs the
   following:

   aclocal
   autoconf
   libtoolize --automake --copy
   automake --foreign -a --copy --include-deps

5. Miscellaneous factors:

   - Compiling with "-xarch=v9" is how one produces 64 bit output with
     the Forte compilers.  Hence, setting CXXFLAGS to -xarch=v9 before
     running configure is how to do this with the attached example.

   - Setting CC and F77 to "cc" and "f77", respectively, although it
     is technically correct (i.e., force configure to find all the
     Forte compilers rather that defaulting to gcc and g77) does not
     affect the outcome of the test.  Since making all three compilers
     match does prevent some spurrious warnings in configure, this
     seems like a Good Idea(tm), but does not change libtool's final
     behavior.

   - Setting CFLAGS and FFLAGS (along with CC and F77) also to
     -xarch=v9 also, albiet technically more correct, does not affect
     the outcome of the test (i.e., it fails either way).

   - Setting LDFLAGS to -xarch=v9 also doesn't appear to affect the
     result (i.e., it always fails).  Doing so simply adds a second
     copy of "-xarch=v9" to the libtool invocation line, and libtool
     ignores/drops that switch as well.

6. Running the following causes the error (config.cache is not
   generated, so it's not a factor):

   setenv CC cc
   setenv CXX CC
   setenv F77 f77
   setenv CXXFLAGS -xarch=v9
   ./configure --enable-shared --disable-static
   make clean all

7. foo.cc and bar.cc files are [correctly] compiled with -xarch=v9,
   producing 64 bit object files.  For example (both automake and
   libtool output):

-----
source='foo.cc' object='foo.lo' libtool=yes \
depfile='.deps/foo.Plo' tmpdepfile='.deps/foo.TPlo' \
depmode=none /bin/bash ./depcomp \
/bin/bash ./libtool --mode=compile CC -DPACKAGE_NAME=\"Libtool\ test\" 
-DPACKAGE_TARNAME=\"libtool-test\" -DPACKAGE_VERSION=\"1.0\" 
-DPACKAGE_STRING=\"Libtool\ test\ 1.0\" -DPACKAGE_BUGREPORT=\"address@hidden" 
-DHAVE_DLFCN_H=1  -I. -I. -xarch=v9 -c -o foo.lo `test -f 'foo.cc' || echo 
'./'`foo.cc
mkdir .libs
 CC "-DPACKAGE_NAME=\"Libtool test\"" -DPACKAGE_TARNAME=\"libtool-test\" 
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"Libtool test 1.0\"" 
-DPACKAGE_BUGREPORT=\"address@hidden" -DHAVE_DLFCN_H=1 -I. -I. -xarch=v9 -c 
foo.cc  -KPIC -DPIC -o .libs/foo.o
-----

   Automake then issues the final link command for libtool, and
   includes the -xarch=v9 switch:

-----
/bin/bash ./libtool --mode=link CC  -xarch=v9    -o liblibtool_test.la -rpath 
/usr/local/lib  foo.lo bar.lo
-----

   But then libtool drops the -xarch=v9 switch when issuing the final
   link command, resulting in an error:

-----
CC -G -nolib -hliblibtool_test.so.0 -o .libs/liblibtool_test.so.0.0.0 
.libs/foo.o .libs/bar.o
ld: fatal: file .libs/foo.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to 
.libs/liblibtool_test.so.0.0.0
-----

    I notice that cut-n-pasting the CC command that libtool executes
    and manually adding "-xarch=v9" makes it link properly:

-----
shell% CC -G -nolib -hliblibtool_test.so.0 -o .libs/liblibtool_test.so.0.0.0 
.libs/foo.o .libs/bar.o -xarch=v9
shell%
-----

I'm afraid that I have zero clue about how libtool works internally,
so I'm unable to offer any help about what to fix and where to apply
it.  Or perhaps there's some automake and/or libtool workaround that
can be used...?  I've tried to be as detailed as possible above, so
please feel free to tell me I've borked up my testing somehow.

Any help would be appreciated.  Thanks.

-- 
{+} Jeff Squyres
{+} address@hidden
{+} http://www.lam-mpi.org/