* Shared Objects and Symbol Overrides @ 1999-09-30 17:46 Eric Todd 1999-09-30 23:56 ` Eric Todd ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Eric Todd @ 1999-09-30 17:46 UTC (permalink / raw) To: help-gcc 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Shared Objects and Symbol Overrides 1999-09-30 17:46 Shared Objects and Symbol Overrides Eric Todd @ 1999-09-30 23:56 ` Eric Todd 1999-10-01 0:00 ` Eric Todd 1999-10-01 16:52 ` Arthur Gold 2 siblings, 0 replies; 9+ messages in thread From: Eric Todd @ 1999-09-30 23:56 UTC (permalink / raw) To: help-gcc 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Shared Objects and Symbol Overrides 1999-09-30 17:46 Shared Objects and Symbol Overrides Eric Todd 1999-09-30 23:56 ` Eric Todd @ 1999-10-01 0:00 ` Eric Todd 1999-10-01 16:52 ` Arthur Gold 2 siblings, 0 replies; 9+ messages in thread From: Eric Todd @ 1999-10-01 0:00 UTC (permalink / raw) To: help-gcc 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-09-30 17:46 Shared Objects and Symbol Overrides Eric Todd 1999-09-30 23:56 ` Eric Todd 1999-10-01 0:00 ` Eric Todd @ 1999-10-01 16:52 ` Arthur Gold 1999-10-04 10:35 ` Eric Todd 1999-10-31 13:57 ` Arthur Gold 2 siblings, 2 replies; 9+ messages in thread From: Arthur Gold @ 1999-10-01 16:52 UTC (permalink / raw) To: help-gcc 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-10-01 16:52 ` Arthur Gold @ 1999-10-04 10:35 ` Eric Todd 1999-10-04 16:32 ` Eric Todd 1999-10-31 13:57 ` Eric Todd 1999-10-31 13:57 ` Arthur Gold 1 sibling, 2 replies; 9+ messages in thread From: Eric Todd @ 1999-10-04 10:35 UTC (permalink / raw) To: help-gcc 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-10-04 10:35 ` Eric Todd @ 1999-10-04 16:32 ` Eric Todd 1999-10-31 13:57 ` Eric Todd 1999-10-31 13:57 ` Eric Todd 1 sibling, 1 reply; 9+ messages in thread From: Eric Todd @ 1999-10-04 16:32 UTC (permalink / raw) To: help-gcc 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" > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-10-04 16:32 ` Eric Todd @ 1999-10-31 13:57 ` Eric Todd 0 siblings, 0 replies; 9+ messages in thread From: Eric Todd @ 1999-10-31 13:57 UTC (permalink / raw) To: help-gcc 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" > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-10-04 10:35 ` Eric Todd 1999-10-04 16:32 ` Eric Todd @ 1999-10-31 13:57 ` Eric Todd 1 sibling, 0 replies; 9+ messages in thread From: Eric Todd @ 1999-10-31 13:57 UTC (permalink / raw) To: help-gcc 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Shared Objects and Symbol Overrides 1999-10-01 16:52 ` Arthur Gold 1999-10-04 10:35 ` Eric Todd @ 1999-10-31 13:57 ` Arthur Gold 1 sibling, 0 replies; 9+ messages in thread From: Arthur Gold @ 1999-10-31 13:57 UTC (permalink / raw) To: help-gcc 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-10-31 13:57 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-30 17:46 Shared Objects and Symbol Overrides Eric Todd 1999-09-30 23:56 ` Eric Todd 1999-10-01 0:00 ` Eric Todd 1999-10-01 16:52 ` Arthur Gold 1999-10-04 10:35 ` Eric Todd 1999-10-04 16:32 ` Eric Todd 1999-10-31 13:57 ` Eric Todd 1999-10-31 13:57 ` Eric Todd 1999-10-31 13:57 ` Arthur Gold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).