bug-libtool
[Top][All Lists]
Advanced

[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: Wed, 25 Apr 2007 12:36:23 -0400

After some more off-list mails with Ralf, I found that non-trivial patches to Libtool must be accompanied by a copyright transfer to the FSF (this is FSF policy).

I understand the rationale for this policy, but I'm told by Cisco lawyers that we cannot do this, unfortunately (long, uninteresting reasons). So the patch that I sent will not make it into Libtool.

I'm told that I can describe the patch in implementation-free terms in the hope that someone else can implement it who either can setup to transfer copyright to the FSF or already has such a transfer agreement in place.

The patch is very simple. It's a test that makes a shared library containing a single instance of a class in the global scope. The class has a specific constructor that should be invoked before main() (since the instance is in the global scope). It is easy enough to test whether the constructor has run before main(); if it has, the test passes. If it has not, the test fails.

Hope that helps.


On Apr 23, 2007, at 10:28 AM, Jeff Squyres wrote:

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)
...etc.

With gcc, it works fine.

Hope this test is helpful.

<pathscale-ctor.at>


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/address@hidden/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 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.)

Thanks,
Ralf


--
Jeff Squyres
Cisco Systems




--
Jeff Squyres
Cisco Systems





reply via email to

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