I'm sure you guys will want to tweak it a bit more (e.g., it blindly uses -shared and doesn't check to see if Libtool has shared library support).
The test itself is pretty simple:- a shared library is created with a global instance of a class that has a static constructor. This constructor should fire before main(). - a trivial application is linked against this library and simply checks to see if the constructor for the global object has fired.
The C++ portion of the test could probably be made a little more simple if desired -- I was testing for something slightly different when we Googled and found the old libtool posting.
The specific cause for the failure is what Peter originally posted -- Libtool is not properly snarfing all the extra libraries/flags from pathCC that it needs (e.g., the library that ensures to call static initializer constructors on global objects).
If you configure libtool with the pathscale suite, you'll see the problem, and test 50 will fail (at least, it's test 50 for me):
% ./configure CC=pathcc CXX=pathCC FC=pathf90 F77=pathf77 [...lots of output...] % make TESTSUITEFLAGS="50" check-local abs_srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd . && pwd`; cd tests; \ CONFIG_SHELL="/bin/sh" /bin/sh $abs_srcdir/tests/testsuite \MAKE="make" CC="pathcc" CFLAGS="-g -O2" CPP="pathcc -E" CPPFLAGS="" LD="/usr/bin/ld -m elf_x86_64" LDFLAGS="" LIBS="-ldl " LN_S="ln -s" NM="/usr/bin/nm -B" RANLIB="ranlib" OBJEXT="o" EXEEXT="" SHELL="/bin/sh" CONFIG_SHELL="/bin/sh" CXX="pathCC" CXXFLAGS="-g -O2" CXXCPP="pathCC -E" F77="pathf77" FFLAGS="" FC="pathf90" FCFLAGS="-g - O2" GCJ="gcj" GCJFLAGS="-g -O2" _lt_pkgdatadir="/home/jsquyres/cvs/ libtool" LIBTOOLIZE="/home/jsquyres/cvs/libtool/libtoolize" LIBTOOL="/ home/jsquyres/cvs/libtool/libtool" tst_aclocaldir="/home/jsquyres/cvs/ libtool/libltdl/m4" 50
## ------------------------ ## ## libtool 2.1a test suite. ## ## ------------------------ ##50: simple test FAILED (pathscale- ctor.at:69)
...etc. With gcc, it works fine. Hope this test is helpful.
pathscale-ctor.at
Description: Binary data
On Apr 23, 2007, at 1:26 AM, Ralf Wildenhues wrote:
[ http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5697 http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5465 ] Hello all, and apologies for the huge delay, * Peter Wainwright wrote on Sun, Jul 23, 2006 at 11:06:36PM CEST:I'm trying to compile a large existing project which uses libtool, using the PathScale C++ compiler. This project has several shared libraries. I found that the constructors for the global objects in these libraries were not being called at all. It turns out that the order of linking objects is wrong: it goes <my objects...> crtbeginS.o crtendS.o instead of crtbeginS.o <my objects...> crtendS.o[...] * Jeff Squyres wrote on Sat, Apr 21, 2007 at 03:09:45AM CEST:Greetings Libtool! Long-time Libtool fan here, reporting that we ran into the exact same bug as described on this list about 8 months ago by Peter Wainwright: http://www.mail-archive.com/bug-libtool@gnu.org/msg00899.html There was no reply to Peter's post on the list; did anyone have a chance to look at his patch, perchance?It was still sitting in my ever-longer queue; sorry.I think a fix for this issue would be a lot easier for me together witha testcase (along the lines of HEAD's tests/template.at) that exposesthis issue. A small self-contained (portable!) example would be a goodstart. This helps ensure that we don't regress with other unrelated compilers. (And testing will then allow me to evaluate whether the patch Peter suggested is good enough.) Thanks, Ralf
-- Jeff Squyres Cisco Systems
_______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool