GNOME Bugzilla – Bug 766669
tests/plugins: xmlsoft_org_xslt_testplugin.la needs -no-undefined
Last modified: 2016-07-13 13:14:08 UTC
Created attachment 328209 [details] [review] add WIN32_EXTRA_LDFLAGS to tests/plugins/Makefile.am Attached patch fixes this compilation problem with Cygwin: CCLD xmlsoft_org_xslt_testplugin.la libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified Makefile:350: recipe for target 'xmlsoft_org_xslt_testplugin.la' failed make[3]: *** [xmlsoft_org_xslt_testplugin.la] Error 1 Thanks!
Created attachment 328210 [details] [review] (alternative) Unconditionally use -no-undefined for libtool libs Actually I'm wondering why to add -no-undefined for win32-based platforms only, while the libs do not require undefined symbols on any platform. What do I miss?
Fixed with the following commit: https://git.gnome.org/browse/libxslt/commit/?id=2fbf5b1f440534a46b7b440a487768620cfb039c Adding -no-undefined unconditionally seems like a good idea, but I don't want to risk breaking the build for other platforms. I also wonder libtool requires -no-undefined on Cygwin. If there aren't any undefined symbols, linking should succeed even without -no-undefined.
Well, Cygwin actually _does_ apply a patch to add the -no-undefined flag, and I'm wondering they haven't filed that already. Without the -no-undefined flag, libtool assumes the library _has_ undefined symbols, and does not even try to link a shared library on platforms known to break with. Instead, library maintainers really should flag -no-undefined always, to unhide undefined-symbol-bugs even on platforms that support them. But agreed, adding -no-undefined by micro version bump is risky - but minor version bump should be fine though. Anyway, thanks!