By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,403 Members | 891 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,403 IT Pros & Developers. It's quick & easy.

Problem with dlopen

P: n/a
Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?

Thanks!
Apr 7 '08 #1
Share this Question
Share on Google+
10 Replies


P: n/a
On 7 Apr 2008 at 17:13, Unknown Soldier wrote:
Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?
Did you link the main program with -rdynamic? If not, only the symbols
the external library knows it needs at link-time will be exported.

Apr 7 '08 #2

P: n/a
In article <ft*********@aioe.org>, Unknown Soldier <no****@nospam.comwrote:
>I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen().
dlopen() is not part of standard C, and the exact operations of
dlopen() depend upon your operating system. Please contact a
development group that deals with your particular operating system.

If I recall correctly from my scanning, on -some- systems,
"backwards" referrals from a shared library can only be implemented
by having the shared library itself dlopen the "earlier" object
(e.g., in your case, the library might have to dlopen() the main
executable.) In other systems, a similar effect might be in place
but rather than having to "manually" dlopen() the earlier objects,
just having the shared library refer to the object in its headers
is enough to trigger a transitive dlopen(). And then there are other
systems that these restrictions don't apply to and it should Just Work,
and other systems on which it should Just Work but only if the
object backwards-referenced was defined as a global object. Different
systems, different rules, so you need to check the rules for -your-
system.
--
"[i]t lacks context, and may or may not make sense."
-- Walter J. Phillips
Apr 7 '08 #3

P: n/a

"Unknown Soldier" <no****@nospam.comwrote in message
I have a program that makes use of external plugins, implemented as shared
libraries loaded at runtime through a call to dlopen(). The libraries
export symbols which the main program collects through a call to dlsym().
It sounds like someone is trying to implement some type of dynamic linking
on top of C. Regular C programs link symbols at link time, they don't call
functions to retrieve lists of symbols.
>
The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.
There are two main possibilities. You might need to link a third library,
or you might need to include functions / symbols in your user program for
dlopen to link in.
>
I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?
Unfortunately although I can help in general terms I don't know exactly how
this specific system works. You might want to try a platform-specific
newsgroup.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Apr 7 '08 #4

P: n/a
In article <ft*********@aioe.org>, Unknown Soldier <no****@nospam.comwrote:
>I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?
It smells like POSIX to me; if true, that means the people in
comp.unix.programmer probably could.
dave

--
Dave Vandervies dj3vande at eskimo dot com
If this confuses you, I would recommend staying away from the shipbuilding
trade, where they measure weight in terms of volume.
--Ben Ketcham in comp.lang.c
Apr 7 '08 #5

P: n/a
That did the trick, thanks a lot for the quick answer!
Antoninus Twink wrote:
On 7 Apr 2008 at 17:13, Unknown Soldier wrote:
>>Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?


Did you link the main program with -rdynamic? If not, only the symbols
the external library knows it needs at link-time will be exported.
Apr 7 '08 #6

P: n/a
Unknown Soldier wrote:
Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?

Thanks!
Do you have some sample code to demonstrate this technique, this sounds
interesting.

Fei
Apr 7 '08 #7

P: n/a
On 7 Apr 2008 at 21:34, Fei Liu wrote:
Unknown Soldier wrote:
>Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?

Thanks!

Do you have some sample code to demonstrate this technique, this sounds
interesting.
Here's a simple example with the shared library code referencing a
symbol from the main executable:
/* prog.c */

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main(void)
{
void (*f)(void);
void *handle;

handle = dlopen ("./shared.so", RTLD_NOW);
if (!handle)
abort();

f = dlsym (handle, "f");
if (!f)
abort();
f();

if(dlclose(handle))
abort();
return 0;
}

void g(void)
{
puts("Calling g...");
}

/* shared.c */

#include <stdio.h>

extern void g(void);

void f(void)
{
puts("Calling f...");
g();
}


$ make prog LDFLAGS=-rdynamic LDLIBS=-ldl
cc -rdynamic prog.c -ldl -o prog
$ make shared.o
cc -c -o shared.o shared.c
$ ld -shared -o shared.so shared.o
$ ./prog
Calling f...
Calling g...

Apr 7 '08 #8

P: n/a
Antoninus Twink <no****@nospam.invalidwrites:
[...]
Here's a simple example with the shared library code referencing a
symbol from the main executable:
[...]

Why don't you post this in comp.unix.programmer?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 7 '08 #9

P: n/a
Keith Thompson <ks***@mib.orgwrites:
Antoninus Twink <no****@nospam.invalidwrites:
[...]
>Here's a simple example with the shared library code referencing a
symbol from the main executable:
[...]

Why don't you post this in comp.unix.programmer?
Because it was requested here and it's in C.

Why do you ask? It seems fairly obvious. You use Gnus. If you are not
interested then kill the thread. Further discussions can move to the
other NG when it starts to deepen.
Apr 7 '08 #10

P: n/a
Antoninus Twink wrote:
On 7 Apr 2008 at 21:34, Fei Liu wrote:
>Unknown Soldier wrote:
>>Hello,

I have a program that makes use of external plugins, implemented as
shared libraries loaded at runtime through a call to dlopen(). The
libraries export symbols which the main program collects through a call
to dlsym().

The problem is that the libraries refer to certain symbols from the main
program. But the linker at runtime fails to resolve these "undefined
symbols" in the shared library.

I think I may have misunderstood something in how dlopen() works - can
anyone give me some advice?

Thanks!
Do you have some sample code to demonstrate this technique, this sounds
interesting.

Here's a simple example with the shared library code referencing a
symbol from the main executable:
/* prog.c */

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main(void)
{
void (*f)(void);
void *handle;

handle = dlopen ("./shared.so", RTLD_NOW);
if (!handle)
abort();

f = dlsym (handle, "f");
if (!f)
abort();
f();

if(dlclose(handle))
abort();
return 0;
}

void g(void)
{
puts("Calling g...");
}

/* shared.c */

#include <stdio.h>

extern void g(void);

void f(void)
{
puts("Calling f...");
g();
}


$ make prog LDFLAGS=-rdynamic LDLIBS=-ldl
cc -rdynamic prog.c -ldl -o prog
$ make shared.o
cc -c -o shared.o shared.c
$ ld -shared -o shared.so shared.o
$ ./prog
Calling f...
Calling g...
Very interesting, thanks a lot!

Fei
Apr 8 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.