kdesrc-build from git master. OS is Manjaro, with KDE Frameworks 5.52 installed at /usr/lib. `kdesrc-build gwenview --include-dependencies --stop-on-failure` died on kdegraphics, where the CMake log revealed the following: [ 86%] Linking CXX executable ../bin/gwenview /usr/bin/ld: /usr/lib/libKF5Baloo.so.5.52.0: undefined reference to `Baloo::Transaction::postingCompIterator(QByteArray const&, QByteArray const&, Baloo::PostingDB::Comparator) const' collect2: error: ld returned 1 exit status make[2]: *** [app/CMakeFiles/gwenview.dir/build.make:567: bin/gwenview] Error 1 make[1]: *** [CMakeFiles/Makefile2:597: app/CMakeFiles/gwenview.dir/all] Error 2 make: *** [Makefile:141: all] Error 2 Looks like it's trying to link against the old 5.52 version of the Baloo shared library that's at /usr/lib/ rather than the one it just compiled five minutes ago that's at ~/kde/usr/lib64/libKF5Baloo.so.5.54.0
See also https://stackoverflow.com/questions/2726993/how-to-specify-preference-of-library-path
Sourcing one of the autogenerated prefix.sh files before running kdesrc-build worked around the issue, presumably because that appends the local lib directory to $QT_PLUGIN_PATH.
That's interesting, because although there's some checks in kdesrc-build for libraries in /usr, it's uniformly to try to *avoid* having libraries in /usr override the defined prefix (which we've seen before as well). We only use CMAKE_PREFIX_PATH and CMAKE_MODULE_PATH (as environment variables) to try to find the other KF5 libraries and those are just set unilaterally to the right value. If it doesn't take too long I'd be interested to know what variable in prefix.sh fixes the kdesrc-build run.
Also wanted to follow up to note that the Stack Overflow answer mentions using LD_LIBRARY_PATH, which we've documented in KF5 that you should *not* use. All KF5/Plasma5 software should successfully link without requiring LD_LIBRARY_PATH, and if it doesn't that's a separate bug (either in the app/lib or in kdesrc-build).
Right, I didn't use LD_LIBRARY_PATH, which is only applicable at runtime anyway, not compile-time. Unfortunately I can no longer reproduce the issue after unsetting all the variables set by prefix.sh and reverting my $PATH. :(
Haven't seen this since; let's call it fixed.