public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: __attribute__((constructor)), shared object files and C++...
@ 2003-05-08 20:05 Pearson, Scott
  2003-05-08 20:07 ` Phil Edwards
  0 siblings, 1 reply; 5+ messages in thread
From: Pearson, Scott @ 2003-05-08 20:05 UTC (permalink / raw)
  To: 'Daniel Jacobowitz', 'Muthukumar Ratty'
  Cc: 'gcc@gcc.gnu.org', 'gcc-help@gcc.gnu.org'

Daniel and Muthu,
 
Thanks for the help (so far).
 
I went back and looked through the HOW-TO documents and other articles that
I was using to educate myself. The item that put me onto the wrong set of
commands was not the HOW-TO, but an article on IBM's web site named "Shared
objects for the object disoriented!"
(www-106.ibm.com/developerworks/library/l-shobj/). Figures...
 
Ok, after looking through the responses I received, I changed my build
sequence for the non-C++ example to:
 
            gcc -fPIC -c libtest.c
            gcc -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0 libtest.o
            ldconfig -v -n .
            ln -sf libtest.so.1 libtest.so
            gcc -o test -L. -ltest test.p
 
...and I now have versioning and executing module constructors/destructors.
 
For the C++ case, I ended up with the (somewhat similar) sequence:
 
            g++ -fPIC -c libctest.cpp
            g++ -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0
libctest.o
            ldconfig -v -n .
            ln -sf libctest.so.1 libctest.so
            g++ -o ctest -L. -lctest -lstdc++ ctest.cpp
 
This didn't work; the module constructors/destructors were not executed.
Where did I go wrong?

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


-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com] 
Sent: Wednesday, May 07, 2003 10:44 AM
To: Muthukumar Ratty
Cc: gcc@gcc.gnu.org; scott.pearson@intel.com
Subject: 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

^ permalink raw reply	[flat|nested] 5+ messages in thread
[parent not found: <D9223EB959A5D511A98F00508B68C20C200D2F2C@orsmsx108.jf.intel.com>]
* __attribute__((constructor)), shared object files and C++...
@ 2003-05-06 23:26 Pearson, Scott
  2003-05-07  8:29 ` Muthukumar Ratty
  0 siblings, 1 reply; 5+ messages in thread
From: Pearson, Scott @ 2003-05-06 23:26 UTC (permalink / raw)
  To: 'gcc-help@gcc.gnu.org'


[-- Attachment #1.1: Type: text/plain, Size: 2192 bytes --]


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> 


[-- Attachment #1.2: Type: text/html, Size: 6750 bytes --]

[-- Attachment #2: libtest.c --]
[-- Type: application/octet-stream, Size: 353 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <errno.h>

static __attribute__((constructor)) void InitSO( void )
{
    printf( "In InitSO()\n" );
}

static __attribute__((destructor)) void ExitSO( void )
{
    printf( "In ExitSO()\n" );
}

void Test( void )
{
    printf( "In Test()\n" );
}

[-- Attachment #3: test.c --]
[-- Type: application/octet-stream, Size: 237 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <errno.h>

extern void Test( void );

int main( int argc, char *argv[] )
{
    printf( "In main()\n" );
    Test();
    return( 0 );
}

[-- Attachment #4: libctest.cpp --]
[-- Type: application/octet-stream, Size: 516 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <errno.h>

#include "libctest.h"

static __attribute__((constructor)) void InitSO( void )
{
    printf( "In InitSO()\n" );
}

static __attribute__((destructor)) void ExitSO( void )
{
    printf( "In ExitSO()" );
}

cTest::cTest()
{
    printf( "In cTest::cTest()\n" );
}

cTest::~cTest()
{
    printf( "In cTest::~cTest()\n" );
}

void cTest::Test( void )
{
    printf( "In cTest::Test()\n" );
}

[-- Attachment #5: libctest.h --]
[-- Type: application/octet-stream, Size: 168 bytes --]

#ifndef _libctest_h
#define _libctest_h

class cTest
{
public:

    cTest();
    ~cTest();
    void Test( void );
};

extern void Other( void );

#endif

[-- Attachment #6: ctest.cpp --]
[-- Type: application/octet-stream, Size: 253 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <errno.h>

#include "libctest.h"

cTest Test;

int main( int argc, char *argv[] )
{
    printf( "In main()\n" );
    Test.Test();
    return( 0 );
}

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-05-08 20:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-08 20:05 __attribute__((constructor)), shared object files and C++ Pearson, Scott
2003-05-08 20:07 ` Phil Edwards
     [not found] <D9223EB959A5D511A98F00508B68C20C200D2F2C@orsmsx108.jf.intel.com>
2003-05-08 17:53 ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2003-05-06 23:26 Pearson, Scott
2003-05-07  8:29 ` Muthukumar Ratty

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).