Linux -> .so files ENTRY POINT?

the 2nd AP is correct, _init is called when the library is loaded.

However, if you''re using C++, this could be a problem, as defining that function will override the compiler''s, which is responsible for things like constructing global objects.

I''m unaware if there''s a solution, at that point I just redesigned so as not to need a function call at load time (or create an init function to be called manually...)

if you are using one of the "newer" g++-versions (2.95.x won't work - i tested 3.2+), you can define global "constructor"-functions. as far as i have tested (some months ago) they work without problems for .so-files.

void myConstructor() __attribute__((constructor));
void myConstructor()
{
// do stuff...
}


didn't do much testing, but everything seemed to work fine for me.



by the way :

... same thing works for destruction, too :

void myDestructor() __attribute__((destructor));
void myDestructor()
{
// do stuff...
}


[edited by - uNiQue0815 on March 17, 2004 5:07:36 PM]

Hmm, since actually only the Linux implementation would be the problem...

I maybe could do what the last AP mentioned but with a _init instead?

The problem I''m having is that I don''t know when to delete the module object in my DLL/SO. I know that LoadLibrary/FreeLibrary is called from each application. So I can be assured that if I could increment/decrement my Object''s refcount at that time, I could tell when to delete the objects that were created in the DLL.

The best sollution would be if I could get some ID from which .exe the LoadLibrary/FreeLibrary was called. Then I could delete only the objects that were created "from" this particular .exe

Thank you all!

architectural misconception.

Linux doesn''t suffer from the Dll drain bamage of creating one single DLL "Instance"

Dynamically linking a .so is EXACTLY like statically linking it, to the progam and to the library. One library to one executable.

No need to worry about more than one program holding references to an object in your library, since no otherp rocess CAN hold references to objects in you library.

If you need to share information amoung instances of this library, looking into shared memory.