Even having 6 GB of RAM, a lot of swap is needed during webkit-gtk building, making my system nearly unusable during building. I think we should consider appending "--no-keep-memory" to LDFLAGS :/ Reproducible: Always
I discovered it in: https://git.gnome.org/browse/gnome-ostree/commit/?id=18e3f786497957cd761a5382d5f60556465de4af Will CC toolchain to verify using this flag doesn't break something
(In reply to comment #1) as i understand it, there shouldn't be any difference to the output
For ignorants like me: --no-keep-memory ld normally optimizes for speed over memory usage by caching the symbol tables of input files in memory. This option tells ld to instead optimize for memory usage, by rereading the symbol tables as necessary. This may be required if ld runs out of memory space while linking a large executable. This looks appropriate here. Maybe we can have a check-reqs handle that though, I have 16G of RAM and I certainly don't want ld to start crunching my drives for no reason.
I will try it next time I need to rebuild webkit-gtk (probably in next bump) ;)
this is done already
This breaks building with gold at least when using binutils-2.24-r1 : >>> Configuring source in /var/tmp/portage/net-libs/webkit-gtk-2.2.4/work/webkitgtk-2.2.4 ... * econf: updating webkitgtk-2.2.4/Source/autotools/config.sub with /usr/share/gnuconfig/config.sub * econf: updating webkitgtk-2.2.4/Source/autotools/config.guess with /usr/share/gnuconfig/config.guess ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-silent-rules --disable-dependency-tracking --disable-coverage --disable-debug --enable-egl --enable-geolocation --disable-gles2 --enable-video --enable-introspection --enable-jit --enable-credential_storage --enable-glx --enable-spellcheck --enable-webgl --enable-accelerated-compositing --with-gtk=3.0 --enable-dependency-tracking --disable-gtk-doc configure: loading site script /usr/share/config.site checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for perl... /usr/bin/perl checking for python... /usr/bin/python2.7 checking for ruby... /usr/bin/ruby checking for bison... /usr/bin/bison checking for mv... /bin/mv checking for gperf... /usr/bin/gperf checking for flex... /usr/bin/flex checking for gawk... gawk checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... no configure: error: in `/var/tmp/portage/net-libs/webkit-gtk-2.2.4/work/webkitgtk-2.2.4': configure: error: C compiler cannot create executables See `config.log' for more details from config.log : configure:3722: checking whether the C compiler works configure:3744: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -Wl,--as-needed -Wl,-O1 -Wl,--no-keep-memory -Wl,--reduce-memory-overheads conftest.c >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: --reduce-memory-overheads: unknown option /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information collect2: error: ld returned 1 exit status You *cannot* ever append random linker or compiler flags without checking that they are valid for the current linker or compiler!
Is there any other ebuild explaining me what is the proper way to check for flags being supported by the linker?
(In reply to Pacho Ramos from comment #7) Hm, that's a very good question :) There is test-flag-PROG, test-flag-CC and test-flag-CXX in flag-o-matic.eclass, but it seems that they can only test compiler flags, not linker flags because they always pass the "-c" flag. Unfortunately, there is no "test-flag-LD" at the moment - so probably the best we can do right now is "$(tc-getLD) --help | grep -- --reduce-memory-overheads"
Maybe flag-o-matic.eclass maintainers would be willing to implement something for testing available ldflags... or, at least, I would CC them to let them know the problem (as maybe other packages could need it in the future)
*** Bug 500206 has been marked as a duplicate of this bug. ***
*** Bug 500958 has been marked as a duplicate of this bug. ***
$summary is bogus, so I couldn't find this bug and filed a duplicate: -Wl,--no-keep-memory is not the problem, -Wl,--reduce-memory-overheads is
(In reply to Pacho Ramos from comment #9) > Maybe flag-o-matic.eclass maintainers would be willing to implement > something for testing available ldflags... or, at least, I would CC them to > let them know the problem (as maybe other packages could need it in the > future) What do you mean? -Wl,- is a CFLAGS since it's passed through gcc to ld What the .ebuild is doing is append-flags passing CFLAGS, not LDFLAGS So no new test is required far as I can tell
So changing... append-ldflags -Wl,--reduce-memory-overheads to... append-ldflags $(test-flags-CC -Wl,--reduce-memory-overheads) should do the trick. testing in a minute to be 100% sure.
Created attachment 370136 [details, diff] Check for ld.gold before passing --reduce-... this works for me. similar code is already used in ntfs-3g's ebuild to check ld.gold
+ 11 Feb 2014; Pacho Ramos <pacho@gentoo.org> webkit-gtk-2.2.4-r200.ebuild, + webkit-gtk-2.2.4.ebuild: + reduce-memory-overheads options is not recognized by ld.gold (#469942 by + Samuli Suominen) +