building KF5 projects against a different Qt5 version (than the one the KF5 frameworks were built against)
René J.V. Bertin
rjvbertin at gmail.com
Sun Apr 26 14:21:34 BST 2020
On Sunday April 26 2020 14:12:01 David Faure wrote:
>> (and possibly LD_PRELOAD).
>
>I don't see why you would set LD_PRELOAD in this configuration.
This may be necessary if even one of the multiple libraries that get loaded has an old-style link to a Qt library which makes it ignore LD_LIBRARY_PATH. I've seen that with libQt5QtCore (and also with libdbus).
>I think this is because the KF5 target brings its own include paths as part of
>the imported target.
Probably, yes. And that's enough to stop the build I was attempting, so I cannot affirm nor infirm if something similar won't happen with linker paths.
>Build against the old Qt, run against the new Qt?
>Then it's back to "only" LD_LIBRARY_PATH switcheroo which works well, while at
>the buildsystem level it's all based upon the old Qt so no mixup there.
Yeah, except that then you can't test those #if QT_VERSION hacks...
Talking about version test hacks (or not-so-hacks): why is it that KFOO_VERSION isn't defined systematically when you include any header of the FOO KF5 framework? With Qt you never have to worry about QT_VERSION being defined. This would be less of an issue if -Wundef was part of -Wall (or if IDE parsers always flagged undefined macros used in a preprocessor expression that isn't a simple #ifdef (or #if defined)...
R.
More information about the Kde-frameworks-devel
mailing list