Hi, when attempting to compile epiphany-2.14.1 (and also previously with 2.14.0) with LDFLAGS set to "-Wl,--as-needed", epiphany fails during the configure stage stating that XPCOM programs either can't be compiled or run (interestingly both mozilla-firefox and mozilla-thunderbird compile and build fine, so perhaps they hold the solution). Below is the error message: checking whether we have a gecko debug build... no checking for gecko version... 1.8 checking for GECKO... yes checking whether we can compile and run XPCOM programs... no configure: error: Cannot compile and run XPCOM programs See `config.log' for more details. And here's the relevant snippet from the config.log file: configure:23400: checking whether we can compile and run XPCOM programs configure:23508: i686-pc-linux-gnu-g++ -o conftest -mtune=pentium4 -march=pentium4 -O2 -fomit-frame-pointer -fno-rtti -fshort-wchar -I/usr/lib/mozilla-firefox/include -I/usr/lib/mozilla-firefox/include -I/usr/lib/mozilla-firefox/include/xpcom -I/usr/lib/mozilla-firefox/include/string -I/usr/include/nspr -I/usr/lib/mozilla-firefox/include/dom -I/usr/lib/mozilla-firefox/include/necko -I/usr/lib/mozilla-firefox/include/pref -Wl,--as-needed -Wl,-R/usr/lib/mozilla-firefox -Wl,-R/usr/lib/nspr -L/usr/lib/mozilla-firefox -L/usr/lib/nspr -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl -Wl,--rpath=/usr/lib/mozilla-firefox conftest.cc >&5 /var/tmp/portage/epiphany-2.14.1/temp/ccjIHx8O.o: In function `main': conftest.cc:(.text+0x5a): undefined reference to `nsCOMPtr_base::begin_assignment()' conftest.cc:(.text+0x80): undefined reference to `NS_CStringContainerInit2' conftest.cc:(.text+0x94): undefined reference to `NS_NewNativeLocalFile' conftest.cc:(.text+0x9e): undefined reference to `NS_CStringContainerFinish' conftest.cc:(.text+0xc2): undefined reference to `NS_InitXPCOM2' conftest.cc:(.text+0xd2): undefined reference to `NS_ShutdownXPCOM' conftest.cc:(.text+0xf3): undefined reference to `nsCOMPtr_base::~nsCOMPtr_base()' conftest.cc:(.text+0x107): undefined reference to `NS_CStringContainerFinish' collect2: ld returned 1 exit status If anyone needs the full thing I'll be happy to provide it. As mentioned mozilla-firefox-1.5.0.2 doesn't seem to fail with this problem, but the only patch I could find that appeared relevant to as-needed was the following: --- mozilla/embedding/browser/gtk/tests/Makefile.in.orig 2005-02-04 00:01:41.000000000 +0100 +++ mozilla/embedding/browser/gtk/tests/Makefile.in 2006-04-28 05:21:10.000000000 +0200 @@ -75,6 +75,8 @@ endif endif +OS_LDFLAGS += -Wl,-rpath-link,'$(DEPTH)/dist/bin' + ifdef MOZ_ENABLE_GTK LIBS += \ -lgtkembedmoz \ And I don't know whether or how that would help here. I'm afraid I don't really know where to start with this once since I don't know how configure scripts are generated or how the test command lines are built up, so any help would be appreciated. Thanks! 5:)
same here too.
Created attachment 86007 [details, diff] epiphany-as-needed-fix.patch patch also the diff to the ebuild coming soon
Created attachment 86008 [details, diff] epiphany-2.14.1.ebuild.patch the diff
As I already said, there is a bug in this version of binutils, if you look at the patch you will clearly see where is the problem, so instead of patching all the world, it is simply better to upstream the issue as this effort goes invain. I've removed the -Wl,rpath... and so on as we already supply this through the pkg-config files.
I disagree with your understanding of the issue, and patch. What you do is just cancelling --as-needed effects by putting it after the various -llib arguments (you could as well have used -Wl,--no-as-needed). The real problem is imo that overloading LDFLAGS the way this m4/gecko.m4 macros do is wrong. Listing the libs in the LIBS variable instead makes AC_RUN_IFELSE do the right thing with linker arguments ordering, and gives a successfull test while preserving the --as-needed option. I will attach a patch which does that.
Created attachment 86013 [details, diff] files/epiphany-2.14.1-as-needed.patch (alternative patch)
(In reply to comment #5) > I disagree with your understanding of the issue, and patch. What you do is > just cancelling --as-needed effects by putting it after the various -llib > arguments (you could as well have used -Wl,--no-as-needed). > > The real problem is imo that overloading LDFLAGS the way this m4/gecko.m4 > macros do is wrong. Listing the libs in the LIBS variable instead makes > AC_RUN_IFELSE do the right thing with linker arguments ordering, and gives a > successfull test while preserving the --as-needed option. > > I will attach a patch which does that. > Are you sure? I'm really not an expert, but there was a difference in the linked libraries in the produced conftest, you could try it yourself. And the other thing is that all this is used only in the tests and not in the compilation of epiphany.
(In reply to comment #7) > Are you sure? I'm really not an expert, but there was a difference in the > linked libraries in the produced conftest, you could try it yourself. A difference beetween what and what? All i say is that linking with "-lfoo -lbar -Wl,--asneeded" (what your patch does) is basically the same as linking with "-Wl,--as-needed -Wl,--no-as-needed -lfoo -lbar", or even just "-lfoo -lbar". In short, it doesn't test whether linking libxpcom with --as-needed is working. > And the other thing is that all this is used only in the tests and not > in the compilation of epiphany. Hiding issues where ./configure is trying to detect them is not a good idea in general. For instance, you could get a linking error later in the build process if libxpcom has some unresolved symbols which are provided by one of the other linked libs (because without --as-needed, the libs are linked anyway, thus it works, but with --as-needed they may not be, thus it may fail).
Comment on attachment 86007 [details, diff] epiphany-as-needed-fix.patch you are right :)
but than I still don't understand why I have differences, so could someone explain ? with your patch 5 libs (working): 0x00000001 (NEEDED) Shared library: [libxpcom.so] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [libxpcom_core.so] with my patch 10 libs (not working): 0x00000001 (NEEDED) Shared library: [libxpcom.so] 0x00000001 (NEEDED) Shared library: [libplds4.so.6] 0x00000001 (NEEDED) Shared library: [libplc4.so.6] 0x00000001 (NEEDED) Shared library: [libnspr4.so.6] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [libxpcom_core.so] and with original line only --as-needed removed 11 libs (even more not working): 0x00000001 (NEEDED) Shared library: [libxpcom.so] 0x00000001 (NEEDED) Shared library: [libplds4.so.6] 0x00000001 (NEEDED) Shared library: [libplc4.so.6] 0x00000001 (NEEDED) Shared library: [libnspr4.so.6] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [libxpcom_core.so] The original line links to libm.so.6, I could provide the tests and commands used, it is only the place of the directives (and of course the last one doesn't have --as-needed at all)
nevermind I have read the TFM :)
Thanks TGL the second patch worked a charm...
FYI, i've sent this upstream: http://bugzilla.gnome.org/show_bug.cgi?id=340560
Fixed in 2.14.1, with no bump.
