similar to bug #329994 the klocalizedstringtest picks up an installed libKF5I18n.so over the newly built one. this causes arbitrary test failures, as the installed version isn't necessarily the version that was newly built one. 1: FAIL! : KLocalizedStringTest::semanticTags() Compared values are not the same 1: Actual (xi18nc("@info:progress", "Checking <emphasis strong='true'>feedback</emphasis> circuits...")): Checking **feedback**(I18N_EXCESS_ARGUMENTS_SUPPLIED) circuits... 1: Expected (QString("Checking **feedback** circuits...")) : Checking **feedback** circuits... 1: Loc: [/home/me/src/git/k/ki18n/autotests/klocalizedstringtest.cpp(274)] this for example happens when running the steps to reproduce with installed ki18n from Jan 15 and newly built (but not installed) ki18n from Jan 17. Reproducible: Always Steps to Reproduce: 1. install ki18n 2. create new build dir 3. cmake && make 4. gdb ./autotests/klocalizedstringtest 5. b KLocalizedStringTest::semanticTags 6. r 7. in a second termial... 8. grep KF5I18n /proc/`pidof klocalizedstringtest`/maps Actual Results: mapped the installed (old) ki18n 7ffff7963000-7ffff79a7000 r-xp 00000000 08:13 659614 /opt/project-neon5/lib/x86_64-linux-gnu/libKF5I18n.so.5.0.0 7ffff79a7000-7ffff7ba6000 ---p 00044000 08:13 659614 /opt/project-neon5/lib/x86_64-linux-gnu/libKF5I18n.so.5.0.0 7ffff7ba6000-7ffff7ba7000 r--p 00043000 08:13 659614 /opt/project-neon5/lib/x86_64-linux-gnu/libKF5I18n.so.5.0.0 7ffff7ba7000-7ffff7ba8000 rw-p 00044000 08:13 659614 /opt/project-neon5/lib/x86_64-linux-gnu/libKF5I18n.so.5.0.0 Expected Results: mapping the not installed (new) ki18n.so
still an issue with latest master
I've tried at random another framework with simple test setup (Sonnet), and the same thing happens there. So I wonder, if this is a more widespread issue, maybe it should be raised on kde-frameworks-devel. (I made a few naive attempts to fix it, but failed.)
Hm. This might actually be a cmake problem. objdump -x autotests/klocalizedstringtest |grep -i runpath RUNPATH /opt/project-neon5/lib:/home/me/src/git/k/ki18n/nb/src since the rpath order is wrong it makes perfect sense that it would first pick up the already installed library. Supposedly the first path is there because that's where it will install and on-install it will then simply strip the last path.
This is fixed nowadays as binaries are rpath'd until they get installed.