[Top][All Lists]
[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
- [ 101415 ] libtool + C++ + gcc on solaris,
nobody <=