On Friday, 2013-09-06, Jan Kundrát wrote:
> On Thursday, 5 September 2013 17:02:47 CEST, Pali Rohár wrote:
> >> - libtrojitaprivate.so shall include code for the basic
> >> plugins which implement e.g. password storage via QSettings
> >
> > Not possible without linker or other hacks.
>
> [...]
>
> > 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.
>
> Thanks for writing this up. The documentation I read only says that one
> should put the Q_IMPORT_PLUGIN "somewhere in the application (in a .cpp
> file)". Some 3rd-party docs [1] explicitly acknowledge that one can include
> a "static plugin" in a shared library.
>
> -> Is there really a problem with adding a *static plugin* into a *shared
> library*?
>
> > 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.
>
> I'm happy that we've reached a consensus here.
>
> > And both hacks are needed *only* for loading *dynamic* plugins if
> > common shared library is not using.
>
> I don't think we have to support this use case.
>
> > 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...
>
> I'd prefer to rely on the dynamic linker to check for "obviously bad"
> installation -- hence my suggestion to move the basic static plugins into a
> required shared library.
>
> > 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...
>
> First of all, users who couldn't be bothered to compile themselves can just
> fetch the nightly builsd from the OBS. It won't get much easier.
>
> Those who for some reason cannot use that are encouraged to follow the
> instructions. When plugins are added to the mix, the instructions will
> include something like this:
>
> 1) cmake -DCMAKE_INSTALL_PREFIX=/opt/trojita ..
> 2) make && make test && make install
> 3) run /opt/trojita/bin/trojita
>
> I also want this whole thing to work right from the build directory without
> invoking `make install`. I believe that this can be done (cmake IIRC does
> all required rpath mangling for us).
>
> What I explicitly do *not* care about are people doing "creative" things
> like moving their build directory somewhere else and expecting that Trojita
> will still work. I just don't see why we should be adding extra code to
> make this work.
>
> > 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.
>
> I'm lost here -- do you object to a single binary linking to 10
> application-specific shared libraries? If so, is there some technical
> argument, or is it a matter of personal preference?
>
> > One problem is there. CMake should not create any static
> > libraries like:
> >
> > add_library(Streams ${libStreams_SOURCES})
> > add_library(qwwsmtpclient ${libqwwsmtpclient_SOURCES})
> > ...
> >
> > But every source C++ file must be added directly to
> > libtrojitaprivate (otherwise link hack is needed)
> >
> > add_library(trojitaprivate ${libStreams_SOURCES}
> > ${libqwwsmtpclient_SOURCES ...)
> >
> > This means radical CMakeLists.txt changes...
>
> Assuming you mean --whole-archive here. Well, it's a pity cmake doesn't
> support it in a portable way. So we basically have three possibilities:
>
> 1) Hardcode --whole-archive and produce the following targets:
>
> - libtrojitaprivate.so
> - libtrojitapluginsprivate.so
> - trojita-kontact.so (linking to libtrojitaprivate.so &
> libtrojitapluginsprivate.so)
> - trojita (small binary linking to libtrojitaprivate.so &
> libtrojitapluginsprivate.so)
> - test_* (small binaries linking to libtrojitaprivate.so), not installed
> - trojita_plugin_*.so (linking to libtrojitapluginsprivate.so)
>
> 2) Produce a ton of shared libraries
>
> - libtrojitaCommon, libtrojitaComposer, libtrojitaIMAP, libtrojitaMSA,
> libtrojitaStreams.so,...
> - libtrojitapluginsprivate.so
> - trojita (linking to all libs)
> - trojita-kontact.so (linking to all libs)
> - test_* (linking to all libs, not installed)
> - trojita_plugin_*.so (linking to libtrojitapluginsprivate.so)
>
> 3) Don't change anything, "waste" some space with duplicated code in both
> standaalone executable and the shared library for Kontact (can we do this?)
>
> - libtrojitapluginsprivate.so
> - trojita (linking to libtrojitapluginsprivate.so), a big size
> - trojita-kontact.so (linking to libtrojitapluginsprivate.so), a big size
> - test_* (not linking to anything unless it works with plugins, not
> installed)
> - trojita_plugin_*.so (linking to libtrojitapluginsprivate.so)
>
> Pali, Thomas, Caspar, Kevin -- which of these do you prefer? I believe that
> 3) actually provides fastest compile times during regular development (i.e.
> the lest to rebuild upon an isolated change), which is somewhat of a one of
> the metrics to me.I am afraid I didn't follow the thread closely enough to understand the problem you are currently facing. I would assume that the library structure would look like this libitrojitapluginsprivate.so -- library plugins link with libtrojitaprivate.so -- library Trojita and Kontact part link with libtrojitaprivate.so would also link libtrojitapluginsprivate.so for the plugin classes/interfaces which are used by both host and plugins so trojita -> libtrojitaprivate -> libtrojitapluginprivate kontact part -> libtrojitaprivate -> libtrojitapluginprivate plugins -> libtrojitapluginprivate A couple of postings mention static linking. Which if those would be static? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
