Created attachment 538304 [details] emerge --info The build log is cluttered with quite a few 'relocation overflow'-messages before it errors out. No idea what that means... lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/ResourceLoadStatistics.cpp.o):ResourceLoadStatistics.cpp:function WebCore::decodeHashCountedSet(WebCore::KeyedDecoder&, WTF::String const&, WTF::HashCountedSet<WTF::String, WTF::StringHash, WTF::HashTraits<WTF::String> >&): error: relocation overflow lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/TextResourceDecoder.cpp.o):TextResourceDecoder.cpp:function WebCore::findTextEncoding(char const*, int): error: relocation overflow lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/cache/CachedResourceLoader.cpp.o):CachedResourceLoader.cpp:function WebCore::logRevalidation(WTF::String const&, WebCore::DiagnosticLoggingClient&): error: relocation overflow collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. * ERROR: dev-qt/qtwebkit-5.212.0_pre20180120::gentoo failed (compile phase): * ninja -v -j3 -l2 failed
Created attachment 538306 [details] build.log.xz
Maybe try with a lower NINJAOPTS value.
Hmm, lowering NINJAOPTS did not help: lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/html/parser/HTMLTreeBuilder.cpp.o):HTMLTreeBuilder.cpp:function WebCore::adjustForeignAttributes(WebCore::AtomicHTMLToken&): error: relocation overflow lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/ResourceLoadStatistics.cpp.o):ResourceLoadStatistics.cpp:function WebCore::decodeHashCountedSet(WebCore::KeyedDecoder&, WTF::String const&, WTF::HashCountedSet<WTF::String, WTF::StringHash, WTF::HashTraits<WTF::String> >&): error: relocation overflow lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/TextResourceDecoder.cpp.o):TextResourceDecoder.cpp:function WebCore::findTextEncoding(char const*, int): error: relocation overflow lib/libWebCore.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/loader/cache/CachedResourceLoader.cpp.o):CachedResourceLoader.cpp:function WebCore::logRevalidation(WTF::String const&, WebCore::DiagnosticLoggingClient&): error: relocation overflow collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. * ERROR: dev-qt/qtwebkit-5.212.0_pre20180120::gentoo failed (compile phase): * ninja -v -j2 -l1 failed
Disclaimer: I am not a developer. I ran into this problem as well. Previous, I had built this package with no problems on my main system (30G available RAM). This time, I was trying to build this package on a new install of a QEMU based Gentoo VM client. After finding this bug report, I made two changes: 1) I changed the amount of memory allocated to the VM client from 512M to 1536M. -m 512M ==> -m 1536M 2) I invoked the emerge commmand: MAKEOPTS="-j1" NINJAOPTS="-l1" emerge =dev-qt/qtwebkit-5.212.0_pre20180120 Package built to completion. I had configured the VM client with a 2G swap partition. Normally, a combined RAM+SWAP total greater than 2G has been adequate to build all packages including the latest version of GCC. At one point, during the previously failed attempt, I had noticed (through a concurrently running instance of 'top') that 1834M of SWAP was used. This observation combined with the previously successful build on both my 32G RAM AMD workstation and 32G RAM INTEL server plus with the NIJAOPTS recommendation earlier in the comments is what led to the two changes above. Another possible factor is that I ran the package build by itself after rebooting the VM client. i.e. The previously failed attempts were run after available memory had become fragmented. I note there are several different build issues with this package entered as bugs. Perhaps these are related. As I am not a developer, all I really know is that I finally got the build to complete successfully. YMMV, good luck!
See also bug# 663770 I ran into a similar problem with building =dev-qt/qtwebengine-5.11.1. I've included the VM client 'emerge --info' and the QEMU invocation script I used in that bug report. For 'qtwebengine', I had to increased the configured memory even more.
I can confirm the issue,the building process completes without issues with MAKEOPTS="-j1" NINJAOPTS="-l1" I don't think it's a viable solution, though. Tue Jan 30 19:00:53 2018 >>> dev-qt/qtwebkit-5.9.1 merge time: 1 hour, 1 minute and 54 seconds. Thu Aug 16 21:42:34 2018 >>> dev-qt/qtwebkit-5.212.0_pre20180120 merge time: 4 hours, 14 minutes and 55 seconds.
I followed you advise regarding the make settings,and as yet the compile has not finished. I did note that although I have a 12G swap it was running out of available virt mem ,I have since added another 60G swap and am living in hope. My system is AMD fm1 asrock A75m 8G mem cpu a4-3600 4 core,I haven't run into this problem before on this machine.
(In reply to Geoff Madden from comment #7) > I followed you advise regarding the make settings,and as yet the compile has > not finished. I did note that although I have a 12G swap it was running > out of > available virt mem ,I have since added another 60G swap and am living in > hope. > My system is AMD fm1 asrock A75m 8G mem cpu a4-3600 4 core,I haven't run into > this problem before on this machine. all completed ok with these settings,so an update to the ebuild is probably the easiest way togo,or could the mem usage be fixed ????.
I'm not sure we have much that we can do here, aside from adding a warning (or even restriction) with regards to available memory. Actual fixes in lowering the use would probably need to go upstream. Luckily we do have the option of using lower "$MAKEOPTS" and/or adding more swap space on them lower RAM set-upses.
Ok, after some positive reports here, I tried building with NINJAOPTS -j1 -l1. This actually worked on my PowerMac G5 (8 GiB RAM), the build completed. Last time I tried, NINJAOPTS -j2 -l1 did not work out. If asked for I could try if the build passes now with -j2 to sort other sources of failure out. Like Chiitoo said in comment #9, adding a warning would be a good idea.
Maybe the warning could contain a suggestion to a workaround, e.g. use https://wiki.gentoo.org/wiki//etc/portage/package.env to reduce MAKEOPTS only for qtwebkit if you do not want to add more memory? I already ran into it back in February 2018, and now again.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3de9ea67c699b9d6a2ab5e22136a00d92c0f35a2 commit 3de9ea67c699b9d6a2ab5e22136a00d92c0f35a2 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-07-19 13:27:24 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-07-19 13:27:33 +0000 dev-qt/qtwebkit: dekeyword ppc The final binary overfows relocation offsets and does not work as-is. Let's dekeyword them following net-libs/webkit-gtk. Bug: https://bugs.gentoo.org/660356 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> dev-qt/qtwebkit/qtwebkit-5.212.0_pre20200309-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
No longer keyworded for ppc. Current dev-qt/qtwebkit-5.212.0_pre20200309-r1 does not build either.
