Skycoder42 / QHotkey

A global shortcut/hotkey for Desktop Qt-Applications
BSD 3-Clause "New" or "Revised" License
548 stars 161 forks source link

Fix the shared library #59

Closed dbermond closed 2 years ago

dbermond commented 2 years ago

Linking client applications to the shared library fails with compilers that do not automatically manage the symbols, like with MSVC 2019.

It looks like that using two definitions to manage which Q_DECL_<...> to use (if Q_DECL_EXPORT or Q_DECL_IMPORT) is hiding the imports on the client application side. When nothing is defined (like on client applications), the Q_DECL_IMPORT seems to become missing, leading to a link error.

It also seems unnecessary and more complicated to use two definitions, while we can use just one to achieve the desired result.

This solves the issue in a pure C++ way, like recommended on the Qt shared library documentation.

Note: CMake documentation states that add_definitions() was superseded by add_compile_definitions(), but this newer counterpart requires CMake 3.14 or later. Used add_definitions() due to CMake 3.1 minimum requirement on QHotkey.

Tested on Arch Linux x86_64 with Qt 6.2.0 and Qt 5.15.2+kde+r234 (both with gcc 11.1.0), and also on Windows 7 with Qt 5.15.2 and MSVC 2019. The shared library builds fine without any modifications, and the client application example also links fine.

Fixes #58

dbermond commented 2 years ago

qmake builds fails on Windows only. CMake passes fine. I wonder what is causing this... :/

Shatur commented 2 years ago

Could you try to remove QHOTKEY_LIBRARY and related macro completely and try again with CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS enabled? This option stops working if you manually export at least one method (or class) in your code.

dbermond commented 2 years ago

Could you try to remove QHOTKEY_LIBRARY and related macro completely and try again with MAKE_WINDOWS_EXPORT_ALL_SYMBOLS enabled?

It does not worked for me. Client application still fails to link.

Situation here is that the current git master code breaks the shared lib for CMake under Windows, but was apparently working for qmake (I cannot test it, qmake does not work for me under Windows, don't know why). If we fix for CMake, it looks like that it breaks for qmake.

Still could not figure out a solution for both.

dbermond commented 2 years ago

I also found it weird. Removed/commented all export references, and it does not work when using that CMake variable.

I found this by the KDE guys. It seems to be the same exact error. If so, they say: Solution: none yet.

Shatur commented 2 years ago

I think I fixed the issue in #60. Could you check it?

dbermond commented 2 years ago

Works perfectly! Thanks! Really appreciated.