pure virtual problems with dlopen()

[Joerg Faschingbauer <jfasch at hyperwave dot com>]

You didn't tell us neither compiler version nor the system you are
working on.

However, for some reason, on some systems a shared library doesn't
become self contained unless you force the linker to make it so. I
obscurely doesn't suffice to just say "link it!".

Some symbols from libgcc.a are *not* copied into the shared library by
default. With gcc 2.7.2.3, I had to explicitly force the following
symbols undefined (using the -u flag to gcc) for Digital UNIX 4.?,
Solaris 2.5.1, HP-UX 10.20. Linux was ok (?).

__eprintf
__pure_virtual
__builtin_delete
__builtin_new
__builtin_vec_delete
__builtin_vec_new
__muldi3
__udivdi3
__umoddi3

Can anybody give a clarification on this?

Joerg


>>>>> "Ralph" == Ralph Seguin <rpseguin@yahoo.com> writes:

Ralph> Hi.  I'm in the process of writing a plugin framework
Ralph> and I've run into a glitch with pure virtual methods
Ralph> and dlopen().  I did some searching and turned up some
Ralph> similar cases, but not obvious fixes.

Ralph> I've got an asbstract base class:  'base'

Ralph> class base
Ralph> {
Ralph> public:
Ralph>     virtual ~base () {}

Ralph>     virtual void someMethod () = 0;
Ralph> };


Ralph> And a derived class: 'derived'

Ralph> class derived : public base
Ralph> {
Ralph> public:
Ralph>     // blah blah blah
Ralph>     virtual void someMethod ()
Ralph>     {
Ralph>         // Do something here.
Ralph>     }
Ralph> };


Ralph> When I compiled derived into an .so  (which isn't
Ralph> quite working as expected either, more on that later),
Ralph> nm shows derived.so as having __pure_virtual being
Ralph> unresolved:

Ralph> outof:rpsPlugin % nm testPlugin.so | fgrep -i pure
Ralph>          U __pure_virtual


Ralph>   I tracked it down in libg++.so and libgcc, but I'm
Ralph> surprised that g++ isn't linking this in whilst I
Ralph> compile:

Ralph> g++  -shared   -Wall -I. -g -shared -c testPlugin.cpp
Ralph> -o testPlugin.o
Ralph> ld   -g   -Bdynamic -shared testPlugin.o -soname
Ralph> testPlugin.so -o testPlugin.so

Ralph> If I make base concrete by giving base::someMethod() a
Ralph> body, dlopen() works (cause __pure_virtual isn't
Ralph> unresolved).


Ralph> For some reason:
Ralph> g++ -shared -Wall -I. -g -c testPlugin.cpp -o
Ralph> testPlugin.so

Ralph> does NOT create something that dlopen() is comfortable
Ralph> with opening, but if I use ld as above, I can dlopen()
Ralph> it.

Ralph> This command just doesn't work as I expect it to:
Ralph> g++ -shared -Wall -I. -g -c testPlugin.cpp -o
Ralph> testPlugin.so -lg++

Ralph> pg++: cannot specify -o with -c or -S and multiple
Ralph> compilations


Ralph> Thanks.
Ralph> -Ralph
Ralph> rpseguin@yahoo.com


Ralph> __________________________________________________
Ralph> Do You Yahoo!?
Ralph> Talk to your friends online with Yahoo! Messenger.
Ralph> http://im.yahoo.com