Created attachment 312325 [details] emerge info while attempting to build the recent kde updates (from 4.8.1 to 4.8.3), nepomuk dies with a number of undefined references: [ 64%] Built target nepomukbackupsync CMakeFiles/nepomukbackup.dir/identifier.cpp.o: In function `Nepomuk::Identifier::run()': /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x262): undefined reference to `Nepomuk::Sync::ResourceIdentifier::mappedUri(KUrl const&) const' /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x468): undefined reference to `Nepomuk::Sync::ResourceIdentifier::unidentified() const' /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x558): undefined reference to `Nepomuk::Sync::ResourceIdentifier::unidentified() const' ... Please note that I recently updated gcc to 4.6.3 to support some experimental work hapening with the LLVM toolchain. I am currently reverting back to 4.5.3 to see if that somehow makes a difference, but that will take a day or more to rebuild the entire system.
Please add full build log
Created attachment 312351 [details] full build log
Try disabling ccache.
I removed ccache from make.config's USE flags and features, and it still fails. In retrospect I thought it might be a different caching, so I did a sync, rebooted the machine, and it still fails. Looking around the net I find mentions of /proc/sys/vm/drop_caches and similar, but I am not sure which, if any, of these would matter. So, if there you are asking me to disable a different cache than ccache, could you please give me a pointer. Thanks
Created attachment 312427 [details] full build log after turning off ccache and setting makeopts to -j1
when I started to revert back to kde*-4.8.1* I realized that the makeoption -j5 might have been playing with the results, so I set it to -j1, and nepomuk died in another place. Latest build log attached.
Is it reproducable, where linking fails? Because I saw yesterday, that your initial build reaches 64% and fails with a completely different error then the one in the build.log posted in the same comment. If it always fails at the same place, it _could_ be a problem with your installation. If not, it looks like a hardware defect (bad RAM, dying HD, ...)
It appears to be a know problem with dragonegg. As soon as I commented out the following line: CFLAGS="${CFLAGS} -fplugin=/usr/lib64/llvm/dragonegg.so" nepomuk-4.8.1-r1 compiled and linked cleanly. At the moment I am rebuilding everything on my system with the 4.6.3 compilers. Once that is done I will try to upgrade to kde-4.8.3 and see if that makes any difference. It will likely take me a couple of days to fully sort this out.
(In reply to comment #7) > Is it reproducable, where linking fails? > Because I saw yesterday, that your initial build reaches 64% and fails with > a completely different error then the one in the build.log posted in the > same comment. If it always fails at the same place, it _could_ be a problem > with your installation. If not, it looks like a hardware defect (bad RAM, > dying HD, ...) Sorry I did not address this before. It did change when I switchd from -j5 to -j1 so that it should effectively turn off parallel compilation, but in both cases would behave consistently.
(In reply to comment #9) > (In reply to comment #7) > > Is it reproducable, where linking fails? > > Because I saw yesterday, that your initial build reaches 64% and fails with > > a completely different error then the one in the build.log posted in the > > same comment. If it always fails at the same place, it _could_ be a problem > > with your installation. If not, it looks like a hardware defect (bad RAM, > > dying HD, ...) > > Sorry I did not address this before. It did change when I switchd from -j5 > to -j1 so that it should effectively turn off parallel compilation, but in > both cases would behave consistently. No, I am not talking about that switch, but your original post: [ 64%] Built target nepomukbackupsync CMakeFiles/nepomukbackup.dir/identifier.cpp.o: In function `Nepomuk::Identifier::run()': /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x262): undefined reference to `Nepomuk::Sync::ResourceIdentifier::mappedUri(KUrl const&) const' /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x468): undefined reference to `Nepomuk::Sync::ResourceIdentifier::unidentified() const' /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/backupsync/gui/identifier.cpp:(.text+0x558): undefined reference to `Nepomuk::Sync::ResourceIdentifier::unidentified() const' ... vs [ 57%] ... CMakeFiles/nepomukstorage.dir/removablemediamodel.o: In function `Nepomuk::RemovableMediaModel::RemovableMediaModel(Soprano::Model*, QObject*)': /var/tmp/portage/kde-base/nepomuk-4.8.3/work/nepomuk-4.8.3/nepomuk/services/storage/removablemediamodel.cpp:(.text+0x96): undefined reference to `Nepomuk::RemovableMediaCache::RemovableMediaCache(QObject*)' CMakeFiles/nepomukstorage.dir/removablemediamodel.o: In function `Nepomuk::RemovableMediaModel::convertFileUrl(Soprano::Node const&, bool) const': ... (build.log, which never reaches the 64% from your first post) But if the problem is due to dragonegg, all is fine (or not ;))
I think the problem was that there were multiple threads and would die at different places. But it seems to be consistent at the moment. I'll keep a watch on it for signs of bad memory, BM, HD, etc. for now ... crankng through the ebuilds...
(In reply to comment #11) > I think the problem was that there were multiple threads and would die at > different places. But it seems to be consistent at the moment. You are right, there are several packages failing with parallel build, even kde packages. But that's not an answer here. I looked deeper into this. /removablemediamodel.cpp:(.text+0x96): undefined reference to `Nepomuk::RemovableMediaCache::RemovableMediaCache(QObject*)' RemovableMediaCache can be found in libnepomukcommon (-> kde-runtime-4.8.3/nepomuk/common/) libnepomukcommon.so is considered for linking in the failing linking command. The funny part: several other targets link successfully against libnepomukcommon (just search your first build.log). If it is (was) dragonegg, it still acts quite weird.
(In reply to comment #11) > > ... > > RemovableMediaCache can be found in libnepomukcommon (-> > kde-runtime-4.8.3/nepomuk/common/) libnepomukcommon.so is considered for > linking in the failing linking command. The funny part: several other > targets link successfully against libnepomukcommon (just search your first > build.log). If it is (was) dragonegg, it still acts quite weird. yes, I thought it quite weird also, but that change seemed to make it work. As a note, the LLVM/clang/dragonegg folks have been actively hunting these things down. So, when I get a little furhter I'll let them know these packages seem to have some trouble.
Please cc kde back if there is anything we can do.
Last rites for sys-devel/dragonegg in progress, bug #543644
