Shared library, QtPlugin, other options?

apampe

I'm lookng for an elegant solution to have a "modular" application and not sure if I'm on the right track or not. The main executable needs to be compiled seperately from a independantly compiled class that can be exchanged prior to runtime, but without recompiling the main executible. This project is on an embedded arm scb, but I'm using Qt for it's websocket library, etc. No gui. The problem is that the main application is large and static taking a long time to build on a little arm cpu, and there is one small extendable class I want to modify, recompile, and rerun with a new extension often. Recompiling the entire application is too timeconsuming at every change to the more dynamic code, let alone every sbc. I have multiple of these machines in the field, running the same parent program different only by the extending class and want to keep sources and compile only once on my test machine.

It's currently functioning as a Qt Library compiled to a .so with a single class that extends a class in the parent application. The extending class calls functions from the parent and others in the parent code. Large application, small .so library that compiles quick.... I thought I had it.

The application runs. I make a change to the addon, recompile and replace /usr/lib/libMyAddon.so. Small changes work, but if i ever do a "make clean" or even just a larger change, then when I replce the libs in /usr/lib/ and retun the parent executable I get:

symbol lookup error: /usr/lib/libProgramLogic.so.0: undefined symbol: _ZN11ModbusTcpIp17readInputRegisterEii

I want to think I'm going about this the right way if I were not to be using Qt. But with Qt something happens with symbols. Maybe this is what the Qt Plugin class then overcomes? I am happy to post some of this code, but could be just going about it an entirely wrong way, so holding off for now.

Is there a qt option to be more consistant with it's symbol names to let me keep things as-is? Should I take another look at the Qt Plugin class, or look in an entirely different direction?

Thanks!

SGaist

Hi,

If a symbol is not found, it's likely that you have modified it one way or another.

From your description, plugins sounds like a good way to go as it allows you to extend your application more easily and you can also keep the plugin themselves small and self-contained.

apampe

OK. I'll give plugins a try. I was hesitant because docs say a class with ONLY virtual functions to be extended in the plugin. My base class I'm extending has lots on non-virtual funtions so I may have to rearrange my class structure to try QtPlugins. But willl give it a go and report back.