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: Open 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 _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
