From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Todd" To: help-gcc@gnu.org Subject: Re: Shared Objects and Symbol Overrides Date: Mon, 04 Oct 1999 16:32:00 -0000 Message-id: References: <37F547EE.A5924FB7@bga.com> <3i5K3.27$4M5.1510@nuq-read.news.verio.net> X-SW-Source: 1999-10/msg00059.html 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 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 > #include > #include > > 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 > > 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 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" > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Todd" To: help-gcc@gnu.org Subject: Re: Shared Objects and Symbol Overrides Date: Sun, 31 Oct 1999 13:57:00 -0000 Message-ID: References: <37F547EE.A5924FB7@bga.com> <3i5K3.27$4M5.1510@nuq-read.news.verio.net> X-SW-Source: 1999-10n/msg00059.html Message-ID: <19991031135700.fiNBgqG44uG7XGXgo4bowM2k_EAkaDAyRz1oT4gNH_M@z> 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 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 > #include > #include > > 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 > > 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 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" > >