libtool
[Top][All Lists]
Advanced

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

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


From: nobody
Subject: [ 101415 ] libtool + C++ + gcc on solaris
Date: Fri, 18 Oct 2002 09:56:07 -0400

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

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

By: David.Decotigny
Date: 2002-Oct-18 09: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




reply via email to

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