[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .ctor section of shared libraries with PathScale compiler

From: Jeff Squyres
Subject: Re: .ctor section of shared libraries with PathScale compiler
Date: Mon, 23 Apr 2007 10:28:30 -0400

With some off-list help from Ralf, I was able to create a .at test that shows the problem (see attached).

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)

With gcc, it works fine.

Hope this test is helpful.

Attachment: 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:


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 with
a testcase (along the lines of HEAD's tests/template.at) that exposes
this issue. A small self-contained (portable!) example would be a good
start.  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.)


Jeff Squyres
Cisco Systems

reply via email to

[Prev in Thread] Current Thread [Next in Thread]