On Thursday 05 September 2013 15:17:07 Jan Kundrát wrote: > I've browsed through the rest of the pali/pali-gsoc branch, > and it looks that commit > 9b769afddc338871148de4a34131d1cdb30cd904 requires a fragile > hack to make this static linking work. I still do not like > this approach. Trojita *already* requires shared libraries > (nobody came to us with cmake patches for linking Qt > statically),
This does not need any cmake patch. It should work fine, if you have in system installed static version of qt libraries. > so moving one small part into another shared > library is not a problem in my opinion. > > So this is what I'd like to achieve by default: > > - Move most of Trojita into a shared library, > libtrojitaprivate.so - Let both the standalone GUI version > and the Kontact plugin link with libtrojitaprivate.so Ok, no problem. > - Move code which is needed in both plugins and the > "application" into libtrojitapluginsupportprivate.so Ok. > - libtrojitaprivate.so shall include code for the basic > plugins which implement e.g. password storage via QSettings Not possible without linker or other hacks. It is possible to include basic plugins into executable but not into dynamic shared library. Maybe you still did not understand where is problem. So I will try to explain it... Qt support two types of plugins: 1. plugin in separate library with own qt_instance function which is exported from library and is loaded and called by high level QPluginLoader class. Only one function with name qt_instance can in shared library, so only one plugin c++ class can be in shared library. This is shared dynamic plugin type. 2. "static" plugin which has own qt_instance_<NAME> function (mangled by C macro at compile time) and which doing some magic. For initializing static plugin is needed to call some Qt macro Q_IMPORT_PLUGIN in main c++ file which will do all magic. And then plugin is available in QPluginLoader in static plugin list. Both types are platform independent, do not needs linker hacks... Everything is done by Qt libraru and Qt macros. So Qt plugins which are statically linked into any executable will work without problem and *without* need for linker hacks (after are initliazed by qt macro). Look at example: https://qt-project.org/doc/qt-4.8/tools-plugandpaint.html But where is our problem: It is not in *plugins*, but in trojita common functions (and classes) in trojita executable. Problem is there only if some *dynamic* (not static!) plugin want to call some function from trojita executable. And working platform/compilter/linker independent solution for this problem (sharing full c++ classes in executable & dynamic library) is moving common functions into separate dynamic shared library. Other one is using special linker flags for including all exported symbols to executable. (That linker hack) > - Any advanced plugins shall be loaded on demand at runtime, > explicitly by the application code. When they are not > available despite user's configuraiton explicitly asking for > them, fall back gracefully (i.e. allow them to work with the > app). > Ok. > When the above is done, we can talk about whether it makes > sense to add an *optional* second mode which would make > *everything* work statically. This second mode, if > implemented, would disable runtime loading of plugins; only > those plugins which are statically linked into the main > binary would be available in this case. This mode only has to > run on Windows because nobody cares about "portable > installation" anywhere else. > Link *everything* statically into one executable with disabled shared dynamic plugins loading will work without any problem on all qt supported platforms and without hacks (see above). > Pali, you have my respect for being able to come up with > creative fixes to the issues you've hit, However, I do not > want to maintain code which calls dlopen directly. To me, > this looks lika a fragile mechanism, something which is > discouraged by Thiago and frowned upon by Thomas. In this > case, I believe that these disadvantages outweight the > benefits. > I understand. Using platform independent calls/funtcions is not good. In all my code, there are only two platform/compiler/linker dependent hacks. First one is direct dlopen call in kontact kpart plugin and second is whole-archive flag for exporting common function from trojita executable. And both hacks are needed *only* for loading *dynamic* plugins if common shared library is not using. > Please feel free to point out problems in this mail, or > present use cases which are made impossible by what I am > proposing. However, please be very specific in what you want > to achieve by this static plugins support, because so far you > have not convinced me. > With static plugins I wanted: 1. include some common plugins into executable, so badly installed trojita application will be able to use at least qsettings passwords... 2. ability to compile trojita binary for specific usage: * trojita with two selected plugins (one password, one addressbook) and everything in one executable or * only kontact kpart dynamic library with static linked kaddressbook and kwallet plugins Some high level users do not need all plugins and one specific which using is enough. Also ability to have one binary with everything copied into eg. ~/bin/trojita without worring where to store plugin library XYZ... I'm tryinto to solve problem: Application installing tons of libraries which are needed for normal operations. Not that application depends on tons of system (or other common gui) libraries used by other applications. -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
