[Qt-interest] Making a Qt program into a dynamic library

[Oliver.Knoll at comit.ch]

Guido Seifert wrote on Wednesday, December 16, 2009 2:49 PM:

>> I'll answer anyway, since more is amiss here...
>> 
>> The extern "C" should not matter since your loader does not access
>> the symbols.
> 
> Believe me, it is. I can reproduce the crash by adding and removing
> this single line. Does not make much sense, I'd expect linker errors
> because of not found symbols,

If you really have a plugin (such as in the example I posted previously) a missing extern "C" would not give you any linker error, at least not at compile/link time. But maybe you mean "link error at runtime", when you dlopen your library.

My expectation, with a missing extern "C", is that the dlsym (GetProcAddress on Windows) would return null. But merely getting a handle on the library should /not/ be affected by a missing extern "C", so dlopen() should still work! And in fact I accidentally verified this with my first approach - me too I initially forgot the extern "C" around my create() function, but LoadLibrary still worked off course. Only the GetProcAddress(handle, "create") then failed, as expected.

The extern "C" merely influences on how the function name is stored in the library, with or without C++ "name mangling" (which is compiler-specific, whereas the naming convention for "C" functions is "standard"). And dlsym()/GetProcAddress only works with exported functions with C naming convention (otherwise they would simply not find the requested symbol).

But when you say "it was the extern "C" which was missing", where exactly did you place it then? Again, it should not have any influence on the outcome of dlopen() - only on dlsym()!


Cheers, Oliver
-- 
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22