Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 416691 - kde-base/nepomuk-4.8.3 fails with undefined references (dragonegg problem)
Summary: kde-base/nepomuk-4.8.3 fails with undefined references (dragonegg problem)
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Bernard Cafarelli
URL:
Whiteboard: dragonegg
Keywords:
Depends on:
Blocks: dragonegg-build
  Show dependency tree
 
Reported: 2012-05-20 08:24 UTC by John (EBo) David
Modified: 2015-09-03 13:40 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge info (emerge-nepomuk-4.8.3,5.90 KB, text/plain)
2012-05-20 08:24 UTC, John (EBo) David
Details
full build log (nepomuk.build.log,601.80 KB, text/plain)
2012-05-20 13:21 UTC, John (EBo) David
Details
full build log after turning off ccache and setting makeopts to -j1 (emerge-nepomuk-4.8.3-build.log,72.58 KB, text/plain)
2012-05-20 23:00 UTC, John (EBo) David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John (EBo) David 2012-05-20 08:24:46 UTC
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.
Comment 1 Agostino Sarubbo gentoo-dev 2012-05-20 11:13:29 UTC
Please add full build log
Comment 2 John (EBo) David 2012-05-20 13:21:06 UTC
Created attachment 312351 [details]
full build log
Comment 3 Franz Trischberger 2012-05-20 13:48:08 UTC
Try disabling ccache.
Comment 4 John (EBo) David 2012-05-20 18:25:32 UTC
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
Comment 5 John (EBo) David 2012-05-20 23:00:38 UTC
Created attachment 312427 [details]
full build log after turning off ccache and setting makeopts to -j1
Comment 6 John (EBo) David 2012-05-20 23:01:33 UTC
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.
Comment 7 Franz Trischberger 2012-05-21 05:32:42 UTC
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, ...)
Comment 8 John (EBo) David 2012-05-21 05:51:09 UTC
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.
Comment 9 John (EBo) David 2012-05-21 05:56:28 UTC
(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.
Comment 10 Franz Trischberger 2012-05-21 06:12:27 UTC
(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 ;))
Comment 11 John (EBo) David 2012-05-21 06:25:59 UTC
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...
Comment 12 Franz Trischberger 2012-05-21 07:30:58 UTC
(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.
Comment 13 John (EBo) David 2012-05-21 12:01:05 UTC
(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.
Comment 14 Andreas K. Hüttel gentoo-dev 2012-07-06 21:03:34 UTC
Please cc kde back if there is anything we can do.
Comment 15 Bernard Cafarelli gentoo-dev 2015-09-03 13:40:46 UTC
Last rites for sys-devel/dragonegg in progress, bug #543644