scope of functions within dynamically loaded libraries

[warz]

test program loads a library i made, containing function titled "halve," then loads another library attempting to use the "halve" function from the previously loaded library. scope of "halve" doesn't extend to anything loaded after it?

warz@keystone:~/C/bot$ ./main
load=/home/warz/C/bot/testdll.so ... OK!
loadandrun=/home/warz/C/bot/testdll2.so ... FAILED!
/home/warz/C/bot/testdll2.so: undefined symbol: halve

Obviously it doesn't. Is there a way to get around this? Maybe the way I've organized the program isn't too good? It currently does something similar to this:

Code Select Expand


program is executed,
- main function loops through file, loading specified libraries
- - library one (testdll.so) is loaded, contains headers and function for "halve"
- - library two (testdll2.so) is loaded, contains function my_init_func(), given the __attribute__((constructor)) type, so it executes the function when it is loaded.
- - - my_init_func() is called from library two, and attempts to use "halve," from library one
- - libraries unloaded
- main returns
program ends.


Obviously I have to somehow extend the definition of "halve" to testdll2.so. How? Maybe thatll help understand how the prgram is (or should be) flowing.

[warz]

I think I might have found the solution. There's an RTLD_GLOBAL flag that can be or'ed into the dlopen function. I also forgot to use dlsym() to introduce the symbols.

Edit: Yeah, threw that in there, and I'm no longer getting unresolve symbols. My attribute constructor function isn't being called after its opened with dlopen() though. HM!

[Kp]

I think I might have found the solution. There's an RTLD_GLOBAL flag that can be or'ed into the dlopen function. I also forgot to use dlsym() to introduce the symbols.

Edit: Yeah, threw that in there, and I'm no longer getting unresolve symbols. My attribute constructor function isn't being called after its opened with dlopen() though. HM!

"Attribute constructor"?  If you mean a global C++ variable, it's likely that the way in which you built the library caused the necessary call not to be placed in _init.  The invocations you're using to compile the source and create the shared objects from the object files would be helpful, as would the line(s) containing the attribute constructor.

[warz]

Alright, a few man page pages said _init and _fini were outdated, or dangerious. It suggested this __attribute__((constructor)). Here's the man page snipit..

The obsolete symbols _init and _fini ... Using  these  routines, or the gcc -nostartupfiles or -nostdlib options, is not recommended. Their use may result in undesired behavior, since the constructor/destructor routines will not be executed (unless  spe­cial measures are taken).

... attribute constructor...

Instead,    libraries    should    export    routines    using    the __attribute__((constructor))   and __attribute__((destructor)) function attributes.  See the gcc info pages for information on  these.   Constructor  routines are executed before dlopen returns, and destructor routines are executed before dlclose returns.

My lines for gcc, etc...

Code Select Expand


>gcc -shared -rdynamic -c -o <output.o> <source.c>
>ld -G <initial.o> -o <result.so>


finally, the code including the attribute constructor, in my library...

Code Select Expand


void __attribute__ ((constructor)) my_init(void)
{
        printf("half of 10 is %u\n", halve(10));
}