dynamic linking

[Sam Steingold]

I have a main program and an add-on module
that uses some functionality in the main program.
E.g., the main program main.c has function foo().
The add-on module in file addon.c calls foo().
I want to compile addon.c into libaddon.so (aka addon.dll) so that it
can later be loaded into a running main program if necessary.

When I try to do that, I get this error:

$ gcc -fPIC -Wl,-export-dynamic -shared -o addon.dll addon.o
addon.o:addon.c(.text+0x???): undefined reference to `_foo'

what am I doing wrong?

--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.iris.org.il> <http://www.memri.org/>
<http://www.openvotingconsortium.org/> <http://ffii.org/>
Are you smart enough to use Lisp?

[Alexei A. Frounze]

"Sam Steingold" <sd*@gnu.org> wrote in message news:uw***********@gnu.org...

I have a main program and an add-on module
that uses some functionality in the main program.
E.g., the main program main.c has function foo().
The add-on module in file addon.c calls foo().
I want to compile addon.c into libaddon.so (aka addon.dll) so that it
can later be loaded into a running main program if necessary.

When I try to do that, I get this error:

$ gcc -fPIC -Wl,-export-dynamic -shared -o addon.dll addon.o
addon.o:addon.c(.text+0x???): undefined reference to `_foo'

what am I doing wrong?

Probably the shared library needs all symbols to be resolved. At any rate,
this is implementation specific and therefore is kind of OT in this group,
which is meant to deal with what's prescribed by the ISO/IEC/ANSI/whatever C
standard.

Instead of requiring that foo function to be available externally, you may
use a callback mechanism: main() calls some function of the library with a
parameter -- address of the foo function. The library then uses this
function indirectly, by function pointer.

Alex

[Ram Wadatkar]

Hi...

I am beginner in Programming .
Can any one tell , me.
How to do dynamic linking for following example...

function main(); writing a file i.e a new function ...foo();
this function foo(); needed to link with the main() function itself in
Run time...

Thanks,

W. Ram

[Sam Steingold]

> * Alexei A. Frounze <ny*****@pung.eh> [2005-09-16 00:39:16 +0400]:

"Sam Steingold" <sd*@gnu.org> wrote in message news:uw***********@gnu.org...

I have a main program and an add-on module
that uses some functionality in the main program.
E.g., the main program main.c has function foo().
The add-on module in file addon.c calls foo().
I want to compile addon.c into libaddon.so (aka addon.dll) so that it
can later be loaded into a running main program if necessary.

When I try to do that, I get this error:

$ gcc -fPIC -Wl,-export-dynamic -shared -o addon.dll addon.o
addon.o:addon.c(.text+0x???): undefined reference to `_foo'

what am I doing wrong?
Probably the shared library needs all symbols to be resolved.

can this resolution be postponed until dlopen?
At any rate, this is implementation specific and therefore is kind of
OT in this group, which is meant to deal with what's prescribed by the
ISO/IEC/ANSI/whatever C standard.
could you please suggest the right group?
Instead of requiring that foo function to be available externally, you
may use a callback mechanism: main() calls some function of the
library with a parameter -- address of the foo function. The library
then uses this function indirectly, by function pointer.

this is not really an option (foo is not the only such function)

--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.palestinefacts.org/> <http://www.mideasttruth.com/>
<http://www.iris.org.il> <http://www.camera.org>
Do not tell me what to do and I will not tell you where to go.

[Alex Fraser]

"Sam Steingold" <sd*@gnu.org> wrote in message news:ui***********@gnu.org...

* Alexei A. Frounze <ny*****@pung.eh> [2005-09-16 00:39:16 +0400]:
"Sam Steingold" <sd*@gnu.org> wrote in message
news:uw***********@gnu.org... [snip]

E.g., the main program main.c has function foo().
The add-on module in file addon.c calls foo().
I want to compile addon.c into libaddon.so (aka addon.dll) so that it
can later be loaded into a running main program if necessary.

[snip] Probably the shared library needs all symbols to be resolved.

can this resolution be postponed until dlopen?

Maybe, but I think it is "going against the grain".

At any rate, this is implementation specific and therefore is kind of
OT in this group, which is meant to deal with what's prescribed by the
ISO/IEC/ANSI/whatever C standard.

could you please suggest the right group?

One with a name containing the name of the OS.

Instead of requiring that foo function to be available externally, you
may use a callback mechanism: main() calls some function of the
library with a parameter -- address of the foo function. The library
then uses this function indirectly, by function pointer.

this is not really an option (foo is not the only such function)

So use an array or struct containing function pointers. Or maybe it would
make sense to put foo() etc into another shared library.

Alex

[Igmar Palsenberg]

Sam Steingold wrote:

Probably the shared library needs all symbols to be resolved.

can this resolution be postponed until dlopen?

The dlopen() manual explains this issue. The RTLD_NOW flag is what you
need. Check the manual of your linker, usually the whole codebase needs
special options (see --export-dynamic when using GNU ld).
could you please suggest the right group?

Some group specific to the target OS.


Igmar