This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __attribute__((constructor)), shared object files and C++...


Scott, the problem's pretty easy: always, always link with the
appropriate driver.  Don't use ld -shared or gcc to link C++ code.  Use
g++.  If you want a soname, add -Wl,-soname,libtest.so.1.

Whatever howto you were working from is wrong, and should be corrected.

On Wed, May 07, 2003 at 10:16:05AM -0700, Muthukumar Ratty wrote:
> 
> 
> Hi, Posting this in gcc list for experts.
> thanks,
> Muthu.
> 
> 
> ---------- Forwarded message ----------
> Date: Tue, 6 May 2003 16:25:53 -0700
> From: "Pearson, Scott" <scott.pearson@intel.com>
> To: "'gcc-help@gcc.gnu.org'" <gcc-help@gcc.gnu.org>
> Subject: __attribute__((constructor)), shared object files and C++...
> 
> 
> Hi
> 
> I have encountered a pair of related problems producing a shared object (SO)
> file which exposes a C++ class.
> 
> First, consider the following non-C++ example. Here's the source for the SO
> file (libtest.c):
> 
>  <<libtest.c>>
> And here's the source for the test program (test.c):
> 
>  <<test.c>>
> 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
> 		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):
> 
>  <<libctest.cpp>>
> And here's the include file (libctest.h; which defines the class):
> 
>  <<libctest.h>>
> And, finally, the test program (ctest.cpp):
> 
>  <<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
> <mailto:scott.pearson@intel.com>
> 







-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]