From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24608 invoked by alias); 7 May 2003 08:29:18 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 23696 invoked from network); 7 May 2003 08:22:45 -0000 Received: from unknown (HELO micaiah.rwc.iqcicom.com) (66.135.128.69) by sources.redhat.com with SMTP; 7 May 2003 08:22:45 -0000 Received: from Muruga.localdomain (unverified [66.135.134.124]) by micaiah.rwc.iqcicom.com (Vircom SMTPRS 2.0.244) with ESMTP id ; Wed, 7 May 2003 01:22:45 -0700 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.6/8.11.2) with ESMTP id h4781fd03889; Wed, 7 May 2003 01:01:41 -0700 Date: Wed, 07 May 2003 08:29:00 -0000 From: Muthukumar Ratty To: "Pearson, Scott" cc: "'gcc-help@gcc.gnu.org'" Subject: Re: __attribute__((constructor)), shared object files and C++... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-05/txt/msg00054.txt.bz2 Hi, I can try to explain the C case... but again, I am not an expert and what I say may be completely wrong :) > <> > If I build the SO file and test program using a command sequence supporting > versioning (as is shown in the Shared Object File HOW-TO), such as: > > gcc -fPIC -c libtest.c > ld -shared -soname libtest.so.1 -o libtest.so.1.0 -lc > libtest.o I looked into the generated ELF file for this case and found that it lacks .init and .fini sections which has the constructors and destructors. So I tried the following gcc -shared -Wl,-soname -Wl,libtest.so.1 -o libtest.so.1.0 -lc libtest.o and I see the .init and .fini sections and the executable calls the constructors and destructors correctly. The explanation I can think of is __attribute__ key word is for gcc and not recognized by ld. I think for ld to recognize the constructors and destructors you need to specify it in the linker script. Sorry I am not familiar with the C++ case. I would really like to know how to make the above C ex. work using ld (using some linker scripts???) Could some one experienced throw some light? Thanks, Muthu > ldconfig -v -n . > ln -sf libtest.so.1 libtest.so > gcc -o test test.c -L. -ltest > > Then I will see (only) the following output: > > In main() > In Test() > > As you can see, the constructor and destructor I included in the SO file are > not executed. > > If, however, I build the application without SO versioning, using the > more-basic set of commands: > > gcc -fPIC -c libtest.c > gcc -shared -o libtest.so libtest.o > gcc -o test test.c -L. -ltest > > Then I will see the following output: > > In InitSO() > In main() > In Test() > In ExitSO() > > As you can see, the constructor and destructor that I included in the SO > file are, in this case, properly executed. > > > That's problem #1; now, let's look at the C++ case. Here's the SO file > source (libctest.cpp): > > <> > And here's the include file (libctest.h; which defines the class): > > <> > And, finally, the test program (ctest.cpp): > > <> > I build the SO file and test program using the following commands, similar > to the (working) non-C++ example above: > > gcc -fPIC -c libctest.cpp > gcc -shared -o libctest.so libctest.o > gcc -o ctest -L. -lctest -lstdc++ ctest.cpp > > The output I get is: > > In cTest::cTest() > In main() > In cTest::Test() > In cTest::~cTest() > > As you can see, the (module-level) constructor and destructor in the SO file > are NOT executed. > > Does anyone have any insights into what's going wrong here? > > TIA, > Scott > > N. Scott Pearson > Staff S/W Architect, Intel Desktop Boards Operation > Desktop Platform Solutions Division, Intel Corporation > Desk 503-696-7818 Cell 503-702-6412 > Fax 503-696-1015 Email scott.pearson@intel.com > > >