A whole Qt program as dynamic link lib?

[Kumosan]

Hi, before I try it myself I'd like to ask if someone has tried this: Is it possible to have a whole Qt program with event loop and all made into a normal non-Qt dynamic lib? I would want to load it into a non-Qt program and control it via a custom interface, e.g. calling a 'start' function should bring up the gui as if it was started from a normal main function.

I don't see a reason why this would not work, but perhaps someone has first hand experiences?

Don't ask me why I need this. Customer wishes. :D

[high_flyer]

It is possible, but makes no sense.
You will have to link Qt statically against your lib, which will make it quite large.
It has other disadvantages too.

Ask your client why he wants this, if he is paying you to code, this means he doesn't know much about coding him self, so he should tell you what is the result he want, not how you should you implement it on a technical level.

[Kumosan]

It is possible, but makes no sense.
You will have to link Qt statically against your lib, which will make it quite large.
It has other disadvantages too.

So it is not possible to have a Qt program as dynlib, which itself loads the qt libs dynamically?



Ask your client why he wants this, if he is paying you to code, this means he doesn't know much about coding him self, so he should tell you what is the result he want, not how you should you implement it on a technical level.

Easy. He wants to add 'programs' to a main program like a dockwidget. But since he does not trust Qt it must not be via a Qt interface. A qt main program and adding functionality as Qt-plugins would be trivial. Unfortunately I have to 'wrap' a Qt program into a non-Qt library. :rolleyes:

[Tanuki-no Torigava]

You can just link dynamically and preload Qt library to speed the process or if Qt libraries resides in some uncommon places where OS cannot find it. This is simple dlload system call. See your OS manual for details.

[Kumosan]

You can just link dynamically and preload Qt library to speed the process or if Qt libraries resides in some uncommon places where OS cannot find it. This is simple dlload system call. See your OS manual for details.

I wish it was so easy. Something I must be doing wrong. I chose in .pro 'lib' as template. Result is, I get a nice .so file. ldd shows all dependencies are fine. But as soon as the link loader tries to load this lib I get a segfault. Even if the lib is totally empty. As long as I have a CONFIG+= qt in my .pro I get a segfault.

[high_flyer]

Easy. He wants to add 'programs' to a main program like a dockwidget. But since he does not trust Qt it must not be via a Qt interface. A qt main program and adding functionality as Qt-plugins would be trivial. Unfortunately I have to 'wrap' a Qt program into a non-Qt library.

It sounds to me you are confusing things, or/and don't understand some other things.
To make sure we all speak the same language lets agree on some definitions:
"Qt vs 'Non Qt" - I am not sure what it is you mean by either.
A Qt application is an application which links against a Qt lib, at the very minimum.
So if you link against Qt, be it dynamically or statically, you have a Qt application.
The question is, if you are using Qt, what sense does it make to wrap it in API that will "shield" you from the Qt API?

The explanation you gave as :

Easy. He wants to add 'programs' to a main program like a dockwidget. But since he does not trust Qt it must not be via a Qt interface.
Doesn't really answer anything.

If he doesn't "trust" Qt (what ever that means), then just don't work with Qt, and that is the end of it.

Again, you can have a Qt lib, and expose from that lib just normal C/C++ API which does not use signals/slots etc.
But the lib it self will be Qt code, so I its just makes no sense.

I suggest you:
1. Get a clear description of what the application should do.
2. Choose the best framework for that task.
3. Tell you customer to worry about what he wants, and let you worry about how to implement it.

[Kumosan]

The question is, if you are using Qt, what sense does it make to wrap it in API that will "shield" you from the Qt API?

Do not ask me, ask my customer. It's a requirement I have and the customer is king.



The explanation you gave as :

Doesn't really answer anything.

If he doesn't "trust" Qt (what ever that means), then just don't work with Qt, and that is the end of it.


I have to use Qt, this is also a requirement. :D
The customer just wants to link several programs into some sort of main program. Therefore I am required to write the programs as dynlibs. But he wants the interface totally Qt free, so he can replace my programs at any times with identical programs, which are not Qt based.

Stupid? Maybe, maybe not. It is as it is and I am doing what I am paid for.



Again, you can have a Qt lib, and expose from that lib just normal C/C++ API which does not use signals/slots etc. But the lib it self will be Qt code, so I its just makes no sense.


Wrong, I can have a Qt lib, which exposes just normal C/C++ API, but still uses
signal/slots internally. Problem was that I did it wrong. That's why I asked here if it is possible at all and how to do it. Not to question the whole architecture, which is not mine and not mine to decide.



I suggest you:
1. Get a clear description of what the application should do.


I did.



2. Choose the best framework for that task.


Can't. I am just a lowly code monkey here.



3. Tell you customer to worry about what he wants, and let you worry about how to implement it.

See above. ;)

[Kumosan]

So, with some help from Qt-interest I found my problem. It is possible to
turn a normal Qt program into a dynlib just by changing in the .pro file the TEMPLATE = app into TEMPLATE = lib (and renaming the main function). My problem was a missing 'extern "C"' line. It is a bit strange, I would have expected that without it I would due to name mangling not be able to find any symbols in my lib, but not that it just segfaults while opening. Long before I am able to even try to access functions in the lib.

Nevertheless, problem solved. I now have a .so file with a function start(int argc, char *argv[]), which can be called from other programs and which brings up my program fully functional.

Customer is happy. I learned something. :D