Problem with dlopen

[Unknown Soldier]

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!

[Antoninus Twink]

Re: Problem with dlopen

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.

[Walter Roberson]

Re: Problem with dlopen

In article <ftdkn7$ig$1@ai oe.org>, Unknown Soldier <nospam@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

[Malcolm McLean]

Re: Problem with dlopen


"Unknown Soldier" <nospam@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

[dj3vande@csclub.uwaterloo.ca.invalid]

Re: Problem with dlopen

In article <ftdkn7$ig$1@ai oe.org>, Unknown Soldier <nospam@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.progr ammer 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

[Unknown Soldier]

Re: Problem with dlopen

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.
>

[Fei Liu]

Re: Problem with dlopen

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

[Antoninus Twink]

Re: Problem with dlopen

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(hand le))
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...

[Keith Thompson]

Re: Problem with dlopen

Antoninus Twink <nospam@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.progr ammer?

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

Re: Problem with dlopen

Keith Thompson <kst-u@mib.orgwrites :

Antoninus Twink <nospam@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.progr ammer?

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.

[Fei Liu]

Re: Problem with dlopen

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(hand le))
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