Re: .ctor section of shared libraries with PathScale compiler

[Jeff Squyres]

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
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/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