On Tuesday, 13 August 2013 13:43:14 CEST, Thomas Lübking wrote:
Pretending this is a reasonable target:
============================
a) -whole-archive is not specific to GCC, but GNU ld - no
matter which compiler invokes it, so that should be tested
instead.
b) the equivalent on CLANG is -force_load <library>, MSVC has
/INCLUDE [1] and /OPT:NOREF [2] - no guarantee that it works at
all (One could look up the dsp's for Qt)
c) simply DO NOT DO THAT.
---------------------
If you want to compile in plugins, just instantiate the objects
based on the plugin name, like
if (pluginName == "ClearTextPassword")
plugin = new ClearTextPassword;
else if (pluginName == "AkonadiAddressbook")
plugin = new AkonadiAddressbook;
else if () ...
else {
// attempt to dlopen plugin library here
}
This will get you the relevant objects referenced and added to
the binary by all compilers that are the least ISO compliant.
And it requires one preprocessor block and CFLAG only.
It will also prevent unneeded bloat (in case there's irrelevant
stuff in the lib you link in this way) and not be acidentally
broken by downstream, tweaking compiler options for
optimization.
I'm assuming that this reply of Thomas applies to commit
f69e2b6f05a8de1de1d447e2bdc0683ab8485e53 as well (i.e. review request
https://git.reviewboard.kde.org/r/112275/diff/3/ ).
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), 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
- Move code which is needed in both plugins and the "application" into
libtrojitapluginsupportprivate.so
- libtrojitaprivate.so shall include code for the basic plugins which
implement e.g. password storage via QSettings
- 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).
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.
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.
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.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
