Consider an executable that is linked with shared object nightcrawler.so
which contain the object file grumpy.o which itself contains function
ratsass(), getting creative here with names;-)
The executable then dlopen() another shared object called andromeda.so which
also contained the object file grumpy.o which itself yes you guess it
contains function ratsass().
Then the executable calls ratsass(), which of the two functions will be
called and is it possible to control which one will be called.
Mario Charest wrote:
Consider an executable that is linked with shared object nightcrawler.so
which contain the object file grumpy.o which itself contains function
ratsass(), getting creative here with names;-)
The executable then dlopen() another shared object called andromeda.so which
also contained the object file grumpy.o which itself yes you guess it
contains function ratsass().
Then the executable calls ratsass(), which of the two functions will be
called and is it possible to control which one will be called.
In general, when one dlopens a shared object, one doesn’t call its
functions directly but rather obtains a reference to them using dlsym.
ie:
typedef int (*ratfunc)(int);
ratfunc *rat_ptr;
void *handle;
handle = dlopen(“andromeda.so”, RTLD_NOW);
rat_ptr = (ratfunc) dlsym(handle, “ratsass”);
rat_ptr(1);
That being said, if the app were to call the function ratsass(), it
should call the one in nightcrawler.so because that is what the loader
will have mapped in at startup.
cheers,
Kris
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:crm99n$c7g$1@inn.qnx.com…
Mario Charest wrote:
Consider an executable that is linked with shared object nightcrawler.so
which contain the object file grumpy.o which itself contains function
ratsass(), getting creative here with names;-)
The executable then dlopen() another shared object called andromeda.so
which also contained the object file grumpy.o which itself yes you guess
it contains function ratsass().
Then the executable calls ratsass(), which of the two functions will be
called and is it possible to control which one will be called.
In general, when one dlopens a shared object, one doesn’t call its
functions directly but rather obtains a reference to them using dlsym.
ie:
typedef int (*ratfunc)(int);
ratfunc *rat_ptr;
void *handle;
handle = dlopen(“andromeda.so”, RTLD_NOW);
rat_ptr = (ratfunc) dlsym(handle, “ratsass”);
rat_ptr(1);
ok
That being said, if the app were to call the function ratsass(), it should
call the one in nightcrawler.so because that is what the loader will have
mapped in at startup.
Thanks Kris
cheers,
Kris
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:crm99n$c7g$1@inn.qnx.com…
Mario Charest wrote:
Consider an executable that is linked with shared object nightcrawler.so
which contain the object file grumpy.o which itself contains function
ratsass(), getting creative here with names;-)
The executable then dlopen() another shared object called andromeda.so
which also contained the object file grumpy.o which itself yes you guess
it contains function ratsass().
Then the executable calls ratsass(), which of the two functions will be
called and is it possible to control which one will be called.
In general, when one dlopens a shared object, one doesn’t call its
functions directly but rather obtains a reference to them using dlsym.
Ok let’s go a little further.
Three shared objects. The first one is link at compile time and the other
two at run time.
Each share objects contain a function call mine(). That function isn’t
called directly by the executable instead it is called by another function
that is inside each of these DLL:
tryme() {
hit(); // in share object link at link-time
hit1(); // pointer obtainned through dlsym of second dll
hit2(); // pointer obtainned through dlsym of second dll
}
Each of these function endup calling mine(). Which instance of mine() will
be called by each perticular function.
Ok let’s go a little further.
Three shared objects. The first one is link at compile time and the other
two at run time.
Each share objects contain a function call mine(). That function isn’t
called directly by the executable instead it is called by another function
that is inside each of these DLL:
tryme() {
hit(); // in share object link at link-time
hit1(); // pointer obtainned through dlsym of second dll
hit2(); // pointer obtainned through dlsym of second dll
}
Each of these function endup calling mine(). Which instance of mine() will
be called by each perticular function.
It depends on the flags passed to dlopen()
The symbols in the executable and the link-time shared objects are
brought into the global scope.
dlopen’s with the default flags will see these symbols, unless you
restrict them with flags.
For a lot more info, read Sun’s excellent doc on this ( a bit Solaris
specific in places, but it’s well written.
http://docs.sun.com/db/doc/816-0559
Also, Ulrich Drepper’s paper, “How To Write Shared Libraries”, at
http://people.redhat.com/drepper/dsohowto.pdf
should be required reading…
Cheers,
Colin
cburgess@qnx.com
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:crs6fe$hd3$1@inn.qnx.com…
Ok let’s go a little further.
Three shared objects. The first one is link at compile time and the
other two at run time.
Each share objects contain a function call mine(). That function isn’t
called directly by the executable instead it is called by another
function that is inside each of these DLL:
tryme() {
hit(); // in share object link at link-time
hit1(); // pointer obtainned through dlsym of second dll
hit2(); // pointer obtainned through dlsym of second dll
}
Each of these function endup calling mine(). Which instance of mine()
will be called by each perticular function.
It depends on the flags passed to dlopen()
The symbols in the executable and the link-time shared objects are brought
into the global scope.
dlopen’s with the default flags will see these symbols, unless you
restrict them with flags.
For a lot more info, read Sun’s excellent doc on this ( a bit Solaris
specific in places, but it’s well written.
Thanks, I was about to ask where I could find some doc cause I have other
scenarios in mind 
I am currently going nuts porting code from Linux which is compose of lots
of shared object cross loading and cross linking.
http://docs.sun.com/db/doc/816-0559
Also, Ulrich Drepper’s paper, “How To Write Shared Libraries”, at
http://people.redhat.com/drepper/dsohowto.pdf
should be required reading…
Cheers,
Colin
cburgess@qnx.com