[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [trojita] [Bug 359709] Windows version crashes after two keystrokes in composer's recipients
From:       Jan Kundrát via KDE Bugzilla <bugzilla_noreply () kde ! or
Date:       2016-02-29 20:28:26
Message-ID: bug-359709-17878-hmDWI25oqJ () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=359709

Jan Kundrát <jkt@kde.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Latest Commit|                            |http://commits.kde.org/troj
                   |                            |ita/2fd5a59886f7720a4ba8321
                   |                            |bb816cf94053fb153
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Jan Kundrát <jkt@kde.org> ---
Git commit 2fd5a59886f7720a4ba8321bb816cf94053fb153 by Jan Kundrát.
Committed on 26/02/2016 at 10:57.
Pushed by gerrit into branch 'master'.

Fix import of plugin symbols on Windows

On Windows, one has to mark the code which lives in a DLL as
Q_DECL_EXPORT when building that DLL, and Q_DECL_IMPORT when using it
from outside of the shared DLL.

The older version of this code was semi-correct -- the plugins
themselves were built in a mode where the PluginManager's methods were
accessed as Q_DECL_IMPORT, the trojita_plugins.dll was built with a
correct Q_DECL_EXPORT. So far so good. However, the main application was
accessing the PluginManager using the default of Q_DECL_EXPORT. This is
a problem because trojita.exe needs to be built with PluginManager being
marked as Q_DECL_IMPORT since the PluginManager itself lives in that
shared DLL.

When the support for shared plugins is disabled (why do we want to
support it in the first place, btw?), there's no reason to use any
dllexport/dllimport bits, so we disable that through a #cmakedefine.

When using the libtrojita_pluygins, though, we have to distinguish if
the PLUGINMANAGER_EXPORT is supposed to expand to Q_DECL_EXPORT or
Q_DECL_IMPORT. Q_DECL_EXPORT should be used only iff the current
translation unit is going to end up in libtrojita_plugins shared
library, otherwise it must be marked as Q_DECL_IMPORT.

The plugins themselves do not have to be marked in any special way due
to the way how the Qt5 plugins work. Their loading and instantiation is
handled by Qt's own code. We do not have direct access to the plugins'
header files or their implementation, so there's no reason to export
their own symbols.
Change-Id: I2128e5d06426e64f9cc3dee0dd2cf510a0769817

M  +3    -0    CMakeLists.txt
M  +5    -5    src/Plugins/AddressbookPlugin.h
M  +2    -2    src/Plugins/PasswordPlugin.h
M  +11   -9    src/Plugins/PluginJob.h
M  +1    -1    src/Plugins/PluginManager.h
A  +1    -0    src/configure-plugins.cmake.in

http://commits.kde.org/trojita/2fd5a59886f7720a4ba8321bb816cf94053fb153

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]