On Saturday, April 25, 2020 2:23:34 PM CEST René J.V. Bertin wrote: > Hi, > > A priori Qt guarantees that you can run binaries against a different, newer > Qt version than they were built against, as long as no private APIs are > used. This also works if that newer Qt version is installed elsewhere, > provided you set LD_LIBRARY_PATH correctly
Yes. > (and possibly LD_PRELOAD). I don't see why you would set LD_PRELOAD in this configuration. > I think this also means you can build code against such a newer (test) Qt > install even if that code uses libraries which were built against the older > Qt version (as long as no mixups occur at runtime; I've done this > successfully with code that uses Phonon, for instance). Yes when Qt itself is upgraded to a newer version. Switching between two Qt prefixes at cmake time is another issue though, which seems to be what you're experiencing. > I'm not having a lot of luck building code that uses KF5 frameworks this > way. Even after getting cmake to find the intended newer Qt version I still > get header conflicts because something inserts unwanted header search > paths. I think this is because the KF5 target brings its own include paths as part of the imported target. > I don't expect there to be official support for this kind of tricky things. > Still, testing code against a new Qt version installed in parallel doesn't > seem to be such an usual thing to do so if there is a trick to this I'd > love to hear it. 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. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5