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