Trouble with shared object

giesbert

Did I understand correct:

you have an executable (the app) that vtries to export classes, that should be used by other binaries (exes, dynamic libraries)?

That is not possible!

You can export stuff from dynamic libraries and use them in executables, but not the other way round.

dorik

That's what I originally thought. But apparently, a shared library can have unresolved symbols that the application can fill in. You can check here: "http://www.informit.com/articles/article.aspx?p=22435&rll=1":http://www.informit.com/articles/article.aspx?p=22435&rll=1

I've made a simple example program before where the shared object contains a subclass of an object in the main app. The shared object does not contain the parent class's definition (only the header), but is resolved when loaded into the main app.

giesbert

Ok, perhaps that works on Linux, but it does definitely not work on windows.

But you would go the safe way, if you put the base class to a dll.

dorik

That is an option. I could try putting the base class in it's own shared object. But, the base class has a static member. If it's linked in to the main application and the shared object, will there be two copies of of the member?

giesbert

please define shared object...

If you mean a dll, then the answer is definitely no, as the dll is only loaded once. IUt doesn't matter if it's a windows dll or a Linux shared library (.so).

dorik

Oh right, I guess that's what shared objects are for! What if the base class was not put into its own shared library, but the definition cpp was put in both the shared library and the main app. Would that cause two static members?

giesbert

YES.

That would create double defined methods and not really 2 static members. On windows, it would have 2 members, on linux only one. The last one wins. If one is of type int and one of type string, the last loaded one is the existing one. Same appears to initialization.

If the member is called static ... inside the cpp file, then it will appear twice, it it's a static member in the class, it will appear once on Linux, twice on windows.

But definitely not what you expect :-(

dorik

I see, thanks for clearing that up!

I would still really like to get it working where the shared object only has the subclass definition. The idea is that there will be many shared objects to work like plugins. They return a pointer to the base class and the main app uses it through polymorphism. I know this is possible but something just isn't working with Qt. I'm quite sure it has to do with moc objects. From what I can see, the base class moc is compiled in with the main app and the subclass moc is compiled into the .so. Why are there undefined symbols?

dorik

Interesting. After compiling the project with and without Wl,--export-dynamic, I checked the output of nm on the executable. I used nm -D to show the dynamic symbols and the output was the same in both cases. So does this mean Wl,--export-dynamic is not doing anything?

I've been including it under QMAKE_CXXFLAGS in my .pro file.

dorik

I found the problem!! :)

So, Qt was including -Wl,--export-dynamic when it compiled each c++ file, but not in the final link. I added it in manually and things seem to work as I had hoped.

Is there another variable I can use in the .pro file?