Updating to kde-base/kdelibs-4.3.5 fails after an ld warning about "creating a DT_TEXTREL in object." [ 37%] Building CXX object kio/CMakeFiles/kio.dir/kssl/ksslutils.o [ 37%] Building CXX object kio/CMakeFiles/kio.dir/kssl/ksslx509v3.o Linking CXX shared library ../lib/libkio.so /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. collect2: ld returned 1 exit status make[2]: *** [lib/libkio.so.5.3.0] Error 1 make[1]: *** [kio/CMakeFiles/kio.dir/all] Error 2 make: *** [all] Error 2 * ERROR: kde-base/kdelibs-4.3.5 failed: * Make failed!
Created attachment 217613 [details] emerge_info.txt emerge --info
Created attachment 217614 [details] build log Full build log.
Created attachment 217616 [details] kdelibs-4.3.5/temp/environment And the environment.
Almost forgot: # emerge -pqv =kde-base/kdelibs-4.3.5 [ebuild U ] kde-base/kdelibs-4.3.5 [4.3.4] USE="acl alsa bzip2 doc fam handbook jpeg2k kerberos lzma mmx nls openexr opengl semantic-desktop spell sse sse2 ssl -3dnow (-altivec) (-aqua) -bindist -debug (-kdeenablefinal) (-kdeprefix) -test -zeroconf" [ebuild U ] kde-base/libknotificationitem-4.3.5 [4.3.4] USE="(-aqua) -debug (-kdeenablefinal) (-kdeprefix)" [ebuild U ] kde-base/kde-env-4.3.5 [4.3.4] USE="(-aqua) (-kdeenablefinal) (-kdeprefix)"
This is the identical error and place that kdelibs-4.3.4 failed to rebuild for me during the @preserved-rebuild following the upgrade to jpeg-8. I was hoping that the upgrade to 4.3.5 would fix it.
You might want to look at http://forums.gentoo.org/viewtopic-p-6151561.html#6151561 I've digged a bit and found that kdelibs builds without acl USE flag. There is a little bit of additional info in the post, which might help to pinpoint the original problem.
I've seen this before. Try deleting every reference of "libacl.a" file from /lib, /usr/lib, /usr/local/lib (or lib64 dirs) and re-emerging sys-apps/acl. In that case, the user had installed the file from some non-portage package by accident.
(In reply to comment #7) > I've seen this before. > > Try deleting every reference of "libacl.a" file from /lib, /usr/lib, > /usr/local/lib (or lib64 dirs) and re-emerging sys-apps/acl. > > In that case, the user had installed the file from some non-portage package by > accident. > That might be it. I found. # locate libacl.a /usr/lib/libacl.a /lib/libacl.a # equery belongs $(locate libacl.a) * Searching for /usr/lib/libacl.a,/lib/libacl.a ... sys-apps/acl-2.2.49 (/usr/lib/libacl.a) No idea where the on in /lib came from. I'll try removing it and report back.
(In reply to comment #8) > (In reply to comment #7) > > I've seen this before. > > > > Try deleting every reference of "libacl.a" file from /lib, /usr/lib, > > /usr/local/lib (or lib64 dirs) and re-emerging sys-apps/acl. > > > > In that case, the user had installed the file from some non-portage package by > > accident. > > > > That might be it. I found. > > # locate libacl.a > /usr/lib/libacl.a > /lib/libacl.a > > # equery belongs $(locate libacl.a) > * Searching for /usr/lib/libacl.a,/lib/libacl.a ... > sys-apps/acl-2.2.49 (/usr/lib/libacl.a) > > No idea where the on in /lib came from. I'll try removing it and report back. > Wait a minute. The one in /lib is a link. I'm going to do a little more investigation first. # ls -l $(locate libacl.a) lrwxrwxrwx 1 root root 17 Jan 7 2008 /lib/libacl.a -> /usr/lib/libacl.a -rw-r--r-- 1 root root 75K Jan 8 22:24 /usr/lib/libacl.a
(In reply to comment #9) > lrwxrwxrwx 1 root root 17 Jan 7 2008 /lib/libacl.a -> /usr/lib/libacl.a 2008? ls: cannot access /lib/libacl.a: No such file or directory Nothing like that here.
Removing symbolic link /lib/libacl.a solves the problem. It seems to be unnecessary.
defiant ~ # l /lib/libacl.a lrwxrwxrwx 1 root root 17 Sep 7 2007 /lib/libacl.a -> /usr/lib/libacl.a defiant ~ # qfile /lib/libacl.a defiant ~ # It seems to be an orphan on my system... I'll delete it and set the build going again.
It might have been a bug in `gen_usr_ldscript` used in acl's ebuild that unnecessarily symlinked the .a file. Dates for that symlink seem to be 2007 and 2008. I'm just closing this as WORKSFORME since nothing owns the link. Please reopen if you figure out a way to reproduce this via portage
Reopen for correct resolution.
*** This bug has been marked as a duplicate of bug 300376 ***
