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?

[quote]
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
[/quote]

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]
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.
[/code]

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.

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!

[quote author=warz link=topic=10792.msg102403#msg102403 date=1109910170]
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!
[/quote]

"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.

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..

[quote]
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).
[/quote]

... attribute constructor...

[quote]
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.
[/quote]

My lines for gcc, etc...

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

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

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