Bugzilla Bug 190744

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 an attachment (id=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 an attachment (id=131135) [details]
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 an attachment (id=131137) [details]
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!