469,904 Members | 2,114 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,904 developers. It's quick & easy.

dynamic linking

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?
Nov 15 '05 #1
5 1564
"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
Nov 15 '05 #2
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

Nov 15 '05 #3
> * 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.
Nov 15 '05 #4
"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
Nov 15 '05 #5
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
Nov 15 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Jeff Hagelberg | last post: by
reply views Thread by Dibyendu Roy | last post: by
2 posts views Thread by Paul E Collins | last post: by
reply views Thread by Pat Sagaser via .NET 247 | last post: by
11 posts views Thread by Sean M. DonCarlos | last post: by
1 post views Thread by zpinhead | last post: by
7 posts views Thread by Ajinkya | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.