|
Home > Archive > Unix Programming > January 2004 > Symbols in shared object
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Symbols in shared object
|
|
| Thomas Degris 2004-01-27, 3:34 am |
| Hello,
in the same process, two libraries (one loaded with dlopen, the other
because of linking dependencies) implementing the same function (its
declaration is in a header file included by both libraries) are loaded
in memory.
I would like to pass the adress of this function as an argument of a
method. So, I would like to know how the first library loaded can pass
the adress of its function, and the second library passes the adress of
its function.
For instance, if I have:
test.h:
extern void test(int arg);
LIBRARY 1:
lib1.c:
#include <test.h>
void test(int arg) {
printf("Test from lib1");
}
libmain1.c:
#include <test.h>
void initlib1() {
register(test);
}
LIBRARY 2:
lib2.c:
#include <test.h>
void test(int arg) {
printf("Test from lib2");
}
libmain1.c:
#include <test.h>
void initlib2() {
register(test);
}
and then, in the process:
main.c:
....
initlib1();
initlib2();
....
I get (if the register function calls its argument) :
Test from lib2
Test from lib2
if the second library is loaded first.
Any hints ?
Thomas
| |
| Robert Harris 2004-01-27, 3:34 am |
| If you want two distinct globally defined fuctions, then you need two
distinct names. And if you have linking dependencies, then you should
resolve them at link time!
Robert
Thomas Degris wrote:quote:
> Hello,
>
> in the same process, two libraries (one loaded with dlopen, the other
> because of linking dependencies) implementing the same function (its
> declaration is in a header file included by both libraries) are loaded
> in memory.
>
> I would like to pass the adress of this function as an argument of a
> method. So, I would like to know how the first library loaded can pass
> the adress of its function, and the second library passes the adress of
> its function.
>
> For instance, if I have:
>
> test.h:
> extern void test(int arg);
>
> LIBRARY 1:
> lib1.c:
> #include <test.h>
> void test(int arg) {
> printf("Test from lib1");
> }
> libmain1.c:
> #include <test.h>
> void initlib1() {
> register(test);
> }
>
> LIBRARY 2:
> lib2.c:
> #include <test.h>
> void test(int arg) {
> printf("Test from lib2");
> }
> libmain1.c:
> #include <test.h>
> void initlib2() {
> register(test);
> }
>
> and then, in the process:
> main.c:
> ...
> initlib1();
> initlib2();
> ...
>
> I get (if the register function calls its argument) :
> Test from lib2
> Test from lib2
>
> if the second library is loaded first.
>
> Any hints ?
>
>
> Thomas
>
| |
| Thomas Degris 2004-01-27, 3:34 am |
| I can't have two distinct globally defined functions because they are
used as entry point to load the library as a plugin. Also, I don't think
the problem comes from the fact that one of the library is loaded
because of linking dependcies.
Thomas
Robert Harris wrote:[QUOTE][color=darkred]
> If you want two distinct globally defined fuctions, then you need two
> distinct names. And if you have linking dependencies, then you should
> resolve them at link time!
>
> Robert
>
> Thomas Degris wrote:
>
| |
| Mohun Biswas 2004-01-27, 6:35 am |
| "man dlsym", paying particular attention to RTLD_SELF.
MB
| |
| Valentin Nechayev 2004-01-27, 9:35 am |
| >>> Thomas Degris wrote:
TD> I can't have two distinct globally defined functions because they are
TD> used as entry point to load the library as a plugin. Also, I don't think
TD> the problem comes from the fact that one of the library is loaded
TD> because of linking dependcies.
You may think it's wrong decision, and I'm likely to agree with this,
but decision for runtime linker behavior in most known unix-like systems
is to prefer known global systems to new loaded ones with the same name.
This also can include main binary if compiled with appropriate options.
[QUOTE][color=darkred]
-netch-
| |
| Thomas Degris 2004-01-27, 8:34 pm |
| Hello,
RTLD_SELF is not mentionned in the man page of dlsym neither it is
defined in any header files in /usr/include. I am running a Debian for
PowerPC.
Thomas
Mohun Biswas wrote:quote:
> "man dlsym", paying particular attention to RTLD_SELF.
>
> MB
>
| |
| Thomas Degris 2004-01-27, 8:34 pm |
| Hello,
quote:
> You may think it's wrong decision, and I'm likely to agree with this,
> but decision for runtime linker behavior in most known unix-like systems
> is to prefer known global systems to new loaded ones with the same name.
> This also can include main binary if compiled with appropriate options.
Sorry, I don't really understand what you're saying... Do you mean I
have to recompile with other options or is it a default behaviour that
is impossible to change ?
Thomas
| |
| Mohun Biswas 2004-01-27, 11:34 pm |
| Thomas Degris wrote:
quote:
> Hello,
>
> RTLD_SELF is not mentionned in the man page of dlsym neither it is
> defined in any header files in /usr/include. I am running a Debian for
> PowerPC.
I use Solaris. Maybe it's a Solaris extension.
MB
|
|
|
|
|