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

[Bob Friesenhahn]

Does

  setenv CXX 'CC  -xarch=v9'

work any better?  I suspect not ...

For gcc, I "fixed" the problem you are experiencing by passing all -m
options.  Unfortunately, this "fix" is not portable across compilers.

There are ways (-Wc,flag -Wl,flag) to force options to be passed to
the compiler or linker, but these are not user friendly, and are
highly tool dependent.

Bob

On Sat, 3 May 2003, Jeff Squyres wrote:

> 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/
>
>
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool
>

======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen