Programming

I've attached a tar.gz containing three tests to demonstrate the problem I'm having.

Within the tar are two shared libraries, two test applications, and a Makefile that builds the three tests.

The shared libaries are libshlib1.so and libshlib2.so. Both export a function, libFunc, which takes a char * argument, buf, and returns it after sprintf'ing an id and the integer result of an external function, mainFunc. The code for both is identical except for the id to differentiate. The function, mainFunc, is located in the main binary that links (or dlopens) the shared library.

The two test applications are test1.c and test2.c. The first, test1.c, simply contains the function mainFunc and calls the library function libFunc. It's really only there to test that the shared library linked normally will find the reference upon load time. This code is compiled to test1.

The second, test2.c, is where the problem lies. It is compiled twice, once linking shlib1 (test2) and the second linking nothing (test3). The code uses dlopen to open the second shared library, shlib2, and upon successfully loading the library it calls libFunc as retrieved by dlsym.

So...now to the problem. Here is the output of the three executables:

Code:

>test1
SHLIB1:1
>test2
Loading shared library [./libshlib2.so]...OK.
SHLIB2:1
>test3
Loading shared library [./libshlib2.so]...ERROR
  [./libshlib2.so: undefined symbol: mainFunc]

As you can see, test3 fails. However, test2, which is identical to test3 except that it links a different shared libarry than it dlopens, succeeds. Oddly, just linking the other library (shlib1) seems to make the linker decide to "promote" the symbol (mainFunc), making it available to shlib2. However, without that link, test3 fails.

Does anyone know why this would be? I compared the output of nm on both test2 and test3 and, except for the addresses, they are identical. I would understand test3 failing if test2 also failed, because neither actually linked the library they dlopen. But, test2 works just fine. Like I said, it's as if just linking a shared library that uses the symbol mainFunc is enough to change something, but I can't see that change in nm's output as shown below:

Code:

>nm test2 | grep mainFunc
08048604 T mainFunc
>nm test3 | grep mainFunc
08048534 T mainFunc

Any ideas?

I don't believe shared libraries are intended to be able to link backwards in that manner. If you must have the shared library call a local function, pass it as a function pointer.

But why, when I link the other library, does it work? That seems odd to me.

Assuming you are using gcc, change your Makefile rule for test3 to include the following linker directive

Code:

-Wl,-export-dynamic

and test3 now works as expected.

Regular executables such as test3 do not export their variables and routines as dynamic symbols by default. You need to use the -export-dynamic directive to specifically export the variables and routines.

In test2.c file the dlopen call should be...

Code:

if ((dl = dlopen(path, RTLD_NOW | RTLD_GLOBAL)) == NULL)

AWESOME! Thanks! I knew there must have been something about the symbols not getting exported, but I didn't know how to fix it.

Edit: I presume, then, that this is why the version that linked the shared library worked, because the linker knew shared libraries were involved with that executable and, thusly, chose to export the symbols. Is there a way I can tell with nm (or some other tool) whether or not the symbols are exported? As I said, I didn't see a difference in nm output...but, maybe I wasn't looking in the right place or asking for the right thing?