Re: Shared Objects and Symbol Overrides

["Eric Todd" <etodd at maxis dot com>]

Arthur,

Below is sample code that illustrates the problem.

For those who are joining late in the game, the puzzle is to convince the
function calls_f(), which is extracted from a library which is manually
loaded at runtime, to use the version of f() found in the library, instead
of the version found in the orignal executable. I.e. The program execution
should be:

>prog
Library
Program

Thanks!
Eric

p.s. I'm using Solaris 2.7 and gcc 2.95.1

---- program.cpp -----
#include <stdio.h>
#include <stream.h>
#include <dlfcn.h>

extern "C"
void f() {
    cout << "Program" << endl;
}

main () {
   void *mHandle;
   void (*fptr)(void);

   mHandle = dlopen("./libLibrary.so", RTLD_NOW);
   if (! mHandle ) {
      char * temp;
      temp = dlerror();
      cout << temp << endl;
   }

   fptr = (void (*)(void))dlsym (mHandle, "calls_f");
   if (!fptr) {
      cout << "Error!" << endl;
   }
   else {
      (*fptr)();
   }
   f();
}
---- end program.cpp ----

---- library.cpp ----
#include <stdio.h>

extern "C"
void f() {
   printf ("Library\n");
}

extern "C"
void calls_f() {
   f();
}
---- end library.cpp ----

---- to build test program ----
g++ -g -c program.cpp  -o program.o
g++ -o prog -ldl program.o
g++ -fPIC -g -c library.cpp -o library.o
g++ -shared -o libLibrary.so  library.o
---- end build ----

---- when prog is run ----
> prog
Program
Program
>
---- end program execution ----
Arthur Gold <agold@bga.com> wrote in message
37F547EE.A5924FB7@bga.com">news:37F547EE.A5924FB7@bga.com...
> Eric:
>
> Show us (or me) your test code.
>
> Your approach _does_ seem correct (I suspect this may be one of those
> "another set of eyes" kinda things).
>
> HTH,
> --ag
>
> BTW - In research I've been doing we're using overrides/preloaded
> libraries quite extensively, so I've probably made most, if not all, of
> the "slap yourself in the forehead" kind of errors ;-0 !!!!
>
>
> Eric Todd wrote:
> >
> > How do you keep functions in a dynamically loaded library from making
calls
> > to functions defined in the executable to which the library is being
linked?
> >
> > In particular, I'm having the following problem, and have checked every
> > source I can find (gcc man page, gcc docs, usenet, simple test program,
> > etc...) but can find no good solution. Any help would be greatly
> > appreciated.
> >
> > I have an executable, say called 'program', which statically links a .o
file
> > that defines a function f(). This version of f() prints a message that
says
> > "program\n".
> >
> >  I also have a dynamically linkable library called 'libA.so' which
defines a
> > function f() and a function calls_f(). The function calls_f()
unsurprisingly
> > calls the function f(), while the version of f() found in the library
prints
> > a message reading "library\n". This library is not linked in any way
(static
> > or dynamic) at compilation of 'program'.
> >
> > In the main of 'program', I call dlopen to load libA.so, and then use
dlsym
> > to get a pointer to calls_f(). I then execute the function pointer so
> > returned. Surprisingly, the result that I get is 'program'! It seems
like
> > what's going on is that when dlopen causes relocation to occur, f() is
bound
> > to the executable's version for both the executable and the library.
> >
> > Is there any way I can keep this from happening? The desired behavior is
for
> > the library's f() to be called when calls_f() (also in the library) is
> > called.
> >
> > FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No,
I'm
> > not using it on the .o files the executable is linking in.
>
> --
> Artie Gold, Austin, TX
> mailto:agold@bga.com or mailto:agold@cs.utexas.edu
> --
> Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"