Re: Shared Objects and Symbol Overrides

["Eric Todd" <etodd@maxis.com>]

For future reference, the solution to the problem described below is to
use -symbolic
when compiling the library, instead of -shared.  Thus, in the example, the
compile line would read:

g++ -symbolic -o libLibrary.so  library.o

This gives the desired results because all global symbols within the library
are bound at compile time, when using the -symbolic option.

Regards,

Eric

Eric Todd <etodd@maxis.com> wrote in message
news: 3i5K3.27$4M5.1510@nuq-read.news.verio.net ...
> 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
> 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"
>
>