GNOME Bugzilla – Bug 756648
fix underlinking
Last modified: 2015-12-16 15:42:18 UTC
Since the split of the library in libyelp and libyelpcommon, the build no longer succeeds on Debian/Ubuntu if gtk-doc is enabled. It fails with the following error: Making all in libyelp make[3]: Entering directory '/home/michael/git/yelp/docs/libyelp' DOC Preparing build DOC Scanning header files DOC Introspecting gobjects /usr/bin/ld: .libs/libyelp-scan.o: undefined reference to symbol 'yelp_settings_get_type' //home/michael/git/yelp/libyelp/.libs/libyelpcommon.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Linking of scanner failed: Makefile:646: recipe for target 'scan-build.stamp' failed make[3]: *** [scan-build.stamp] Error 1 make[3]: Leaving directory '/home/michael/git/yelp/docs/libyelp' Makefile:415: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/michael/git/yelp/docs' Makefile:537: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/michael/git/yelp' Makefile:446: recipe for target 'all' failed make: *** [all] Error 2
Created attachment 313381 [details] [review] [PATCH] Fix underlinking in API documentation build
Steps to reproduce would be welcome.
Use a Debian or Ubuntu build environment, then run ./autogen.sh --enable-gtk-doc && make in a fresh git checkout. The important bit is to use the libtool version provided by Debian. This will generate a ./libtool file where link_all_deplibs=no is set. The ./libtool file shipped by the upstream tarball has link_all_deplibs=unknown. So an alternative is to hack your local ./libtool file and set "no" instead of "unknown".
Ugh, that sounds rather Debian-specific. If it's not something I can easily reproduce, it's likely that the bug will be reintroduced again later. I am not keen to add a fix without a good way to reproduce it.
While this might be Debian/libtool specific, it points at a real issue. I provided two ways how to reproduce it. That said, rest assured that the Debian GNOME maintainers will continue to file bug reports once they pop up.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702737 has some more background
Very well, in that case I suggest that you keep the distribution patch as just that.
As I tried to explain, this points at a real issue. You are using symbols from libyelpcommon in the gtk scanner, so you should better link against it. That it currently works is just by accident. I don't understand your objection, tbh.
Too bad, this will make it harder for users coming from Debian/Ubuntu would like contribute to yelp and build the package from source. Sounds to me more like a not a fedora problem, not my problem. Unfortunately I see that quite often :-/
*** Bug 759457 has been marked as a duplicate of this bug. ***
(In reply to Michael Biebl from comment #8) > As I tried to explain, this points at a real issue. > You are using symbols from libyelpcommon in the gtk scanner, so you should > better link against it. I agree with this. I filed today bug 759457 after finding the same issue and proposing exactly the same patch, as it's my understanding that you should be linking against all the internal static libraries you're using symbols from. > That it currently works is just by accident. I don't think it's by accident either, since some linkers to resolve the A > B > C patch when a program A uses a symbol from library C while only linking against B. But IMHO that does not mean it's the right thing to do, and specially in this case that all the linking is happening against an internal static library I honestly don't see any good reason not to add libyelpcommon.la. But I might be missing something, in that case I'd appreciate some further clarification, since as it is now this is basically making it harder for people to build from sources.
Looks like this is no longer an issue after having the patch for 756654 landed in master (which removed libyelpcommon.so).