[ 101415 ] libtool + C++ + gcc on solaris

[nobody]

Support Request #101415, was updated on 2002-Oct-18 08:55
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25

Category: None
Status: Deleted
Priority: 5
Summary: libtool + C++ + gcc on solaris

By: rboehne
Date: 2002-Oct-22 08:28
Logged In: YES 
user_id=148
Browser: Mozilla/4.76 [en] (X11; U; OSF1 V4.0 alpha)

This is a canned response from the Libtool maintainers
regarding your support inquiry.  Your inquiry left out
the crucial detail of which version of Libtool you
are having trouble with.  Please read
http://www.gnu.org/software/libtool/libtool.html
where it concerns posting to the bug-libtool mailing list:

 If you think you have found a bug in libtool, then you should,
in the first instance send as complete a report as possible to
this list, including the version of Libtool that you are using.
Ideally, you should include the text you get by running
config.guess, the text you see when you run configure, and if you
can, a patch made with diff -u5 which fixes the problem.  If you
can send a small script, modelled after the scripts in the tests
directory of the distribution which fails with the unpatched
distribution, but passes with your patch applied we can add the
test to the distribution to make sure the bug doesn't reappear.

----------------------------------------------------------------------

By: David.Decotigny
Date: 2002-Oct-18 08:55
Logged In: NO 
Browser: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827

We have gcc-3.2 here compiled using:
  --enable-shared --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld

When configure runs libtool, it discovers that gcc does
not use a GNU ld, which is just the case. So, when
creating a shared library, it will be the case that
libtool will "manually" invoke the ld (/usr/ccs/bin/ld
here). Why not... BUT...

The library works fine as long as there are no C++
global objects that are expected to be constructed
before main() (ie global objects declared in a c++
source as "MyClass object(init_parameters)). If there
are such objects, the behavior any program dynamically
linked against the library is to simply ignore them, or
to crash in the middle of the objects instanciations... 

I noticed that building the library manually with
"gcc-3.2 -shared" instead of the "ld" command line set
by libtool, will result in a correct behavior:
everything will be correctly initialized before main().
If I add the crtbegin/crti/crtend objects in the
library, it actually seems to work fine too.

So the question: why try to guess a (apparently broken)
ld command line, since gcc -shared seems to do the job
right?

----------------------------------------------------------------------
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=101415&group_id=25