Greetings all,
While trying to build a shared library that makes use of the STL
with the SunWorkshop C++ compiler 4.2 on Solaris 2.6, I have found
the Sun's CC does not work quite right if, when building the shared
library, .lo files are specified as the objects to link. The compiler
does not recognize the .lo's as linkable objects and ignores them,
resulting in undefined symbols.
If I manually replace the .lo's on the command line with the corresponding
.o's, everything works as advertised.
Therefore, is there a way to force libtool to link the
.o's rather than .lo's?
Also, almost everything works after changing all the .lo's to .o's.
However, with Sun's C++ compiler, every STL member of each template
instantiation becomes a .o file placed in a directory
named by -ptr (which is passed to both the compiler and the linker).
(I have been informed that this behavior has now been adopted by ANSI
and should be appearing in additional C++ compilers in the future)
To get proper behavior one must build with -ptrdatabase.
Below is a minimalistic test taken from my acinclude.m4 file
to check whether CXXFLAGS needs a -ptr argument.
---------------------------------------
dnl
dnl AC_PROG_CXX_TEMPLATE_DB
dnl
AC_DEFUN(AC_PROG_CXX_TEMPLATE_DB,
[
AC_MSG_CHECKING([whether the C++ compiler ($CXX $CXXFLAGS $LDFLAGS) accepts -ptr])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
ac_save_CXXLAGS="$CXXFLAGS -ptrbuild.ptrep"
AC_TRY_COMPILER([int main(){return(0);}], ac_cv_prog_cxx_template_db,
ac_cv_prog_cxx_template_db_cross)
CXXFLAGS="$ac_save_CXXFLAGS"
AC_LANG_RESTORE
AC_MSG_RESULT($ac_cv_prog_cxx_template_db)
if test $ac_cv_prog_cxx_template_db = yes; then
LDFLAGS="$LDFLAGS -ptrbuild.ptrep"
CXXFLAGS="$CXXFLAGS -ptrbuild.ptrep"
fi
])
