sf...@users.sourceforge.net:
> Hmm, dlopen(3) in test_dlopen("Test_FuncB") seems to load the Test_FuncA
> library. It might be a specification of dlopen().
By specifing LD_DEBUG, I could confirm dlopen(3) loads the library for
Test_FuncA while it is given the lib for Test_FuncB. It happened in
user-space.
Generally
- dlopen() searches the internal list of .so which are already loaded.
- if the given .so is found in the list, dlopen() simply increments the
reference counter of it, and returns its handle.
- dlclose() decrements the reference counter of given handle, and when
it reaches zero, the loaded .so will be freed.
In your case,
- dlopen("libTest_FuncA") succeeded
- dlopen("libTest_FuncB") succeeded too, but dlopen() thinks
"libTest_FuncA is given again." and it returns the same handle to
libTest_FuncA.
- obviously the test program cannot find "Test_FuncB" in "libTest_FuncA".
But still I don't know whether it is an expected behaviour of dlopen()
or not.
Possible causes may be in one of these (or more).
- libraries in ubuntu (libc, libdl).
- aufs, which makes something wrong and it makes libdl confused.
- ubuntu kernel, which makes something ... (ditto).
Wojciech, did you succeeded compiling latest aufs on ubuntu?
J. R. Okajima
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
