[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LT 1.5: problem with Solaris Forte 64 bit shared C++ libraries
From: |
Jeff Squyres |
Subject: |
LT 1.5: problem with Solaris Forte 64 bit shared C++ libraries |
Date: |
Sat, 3 May 2003 09:10:14 -0400 (EDT) |
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/
- LT 1.5: problem with Solaris Forte 64 bit shared C++ libraries,
Jeff Squyres <=