gnustep-base/gnustep-base-1.14.0 uses tools to generate the documentation that somehow get linked to non-existent (when binutils isn't 2.17) libraries and then fail when ran to generate the docs. Is this an issue of gnustep-base-1.14.0 depending on not having binutils-2.18 installed? If so, the ebuild should perhaps know about it, at least until it's fixed in gnustep-base. Reproducible: Always Steps to Reproduce: 1. emerge =sys-devel/binutils-2.18 2. USE=doc emerge =gnustep-base/gnustep-base-1.14.0 Actual Results: After successfully compiling/installing the code, while it's building the documentation files, it breaks: Making all for doc ReleaseNotes... ../Tools/obj/autogsdoc -Project ReleaseNotes -DocumentationDirectory ReleaseNotes -MakeDependencies ReleaseNotes/dependencies ReleaseNotes.gsdoc ../Tools/obj/autogsdoc: error while loading shared libraries: libbfd-2.17.so: cannot open shared object file: No such file or directory make[1]: *** No rule to make target `ReleaseNotes/dependencies', needed by `internal-doc-all_'. Stop. make: *** [ReleaseNotes.all.doc.variables] Error 2 * * ERROR: gnustep-base/gnustep-base-1.14.0 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_install * ebuild.sh, line 1089: Called qa_call 'src_install' * ebuild.sh, line 44: Called src_install * gnustep-base-1.14.0.ebuild, line 50: Called gnustep-base_src_install * gnustep-base.eclass, line 73: Called egnustep_doc * gnustep-base.eclass, line 158: Called die * * doc make failed When it's compiling the tools, the one that fails in particular, I noticed this: Making all in Tools... make[1]: Entering directory `/var/tmp/portage/gnustep-base/gnustep-base-1.14.0/work/gnustep-base-1.14.0/Tools' Making all for tool autogsdoc... [lots of compiling object files goes here] x86_64-pc-linux-gnu-gcc -rdynamic -Wl,-rpath=/usr/GNUstep/System/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -shared-libgcc -fexceptions -fgnu-runtime -o obj/gdnc \ ./obj/gdnc.o \ -L../Source/./obj -L/var/tmp/portage/gnustep-base/gnustep-base-1.14.0/temp/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -Wl,-rpath=/usr/GNUstep/System/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -L/usr/GNUstep/System/Library/Libraries/gnu-gnu-gnu -L/usr/GNUstep/System/Library/Libraries -L/usr/lib -lgnustep-base -lpthread -lobjc -lgmp -lxslt -lxml2 -lz -lm -lcallback -lavcall -lbfd -liberty -ldl -lz -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libbfd-2.17.so, needed by /usr/GNUstep/System/Library/Libraries/libgnustep-base.so, not found (try using -rpath or -rpath-link)
Created attachment 129591 [details] emerge --info Attached emerge --info; note the line about binutils: sys-devel/binutils: 2.18
have you ran revdep-rebuild? Updating your binutils always breaks gnustep.
Revdep-rebuild wants to do emerge --oneshot =dev-util/libconf-0.42.10-r1 =gnustep-base/gnustep-base-1.14.0 =gnustep-base/gnustep-gui-0.12.0 =gnustep-base/mknfonts-0.5-r1 =gnustep-base/gnustep-back-art-0.12.0 It is indeed broken, and tries to fix it by emerging the latest version, which fails because of USE=doc.
ok, this needs some patching, I (or someone else) need to look into the makefiles how to get it to use the just compiled binaries instead.
The correct binary is used: AUTOGSDOC=../Tools/$(GNUSTEP_OBJ_DIR_NAME)/autogsdoc However it uses the system gnustep lib (still linked to the old binutils lib), and not the new one... A hack could be to change this AUTOGSDOC to force library path... Btw, did re-merging gnustep-base another time fix your problem?
The only way out here seems to be to set LD_LIBRARY_PATH to the libs in the install tree. I think we should fix this in the ebuild when the doc USE-flag is set. I'll try and see if I can come up with a patch today.
Created attachment 131135 [details, diff] gnustep-base patch @original reporter: do you still have the same situation, or did you emerge gnustep-base without doc in the meanwhile? The attached patch should solve things. I still compiles for me, but I couldn't test as downgrading binutils in general is a bad idea.
Created attachment 131137 [details, diff] gnustep-base patch Right... not really awake. This should be the correct patch.
I hit the problem on my Solaris 10/Sparc machine. The patch I attached here is wrong, but I am testing a new one at the moment. That hopefully closes this bug.
Fixed in CVS, thanks!
