Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 700988 - dev-qt/qtwebengine-5.12.5 fails emerge: obj/third_party/blink/renderer/platform/platform/iir_filter.o
Summary: dev-qt/qtwebengine-5.12.5 fails emerge: obj/third_party/blink/renderer/platfo...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-23 14:55 UTC by Noel Bennett
Modified: 2020-10-03 17:57 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Build Log (build.log.bz2,510.16 KB, application/x-bzip)
2019-11-23 14:55 UTC, Noel Bennett
Details
Output of emerge --info (emerge.info,6.18 KB, text/plain)
2019-11-23 14:56 UTC, Noel Bennett
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Noel Bennett 2019-11-23 14:55:57 UTC
Created attachment 597152 [details]
Build Log

Upgrading to dev-qt/qtwebengine-5.12.5 results in an internal compiler error, stemming from a failure on line 20387: FAILED: obj/third_party/blink/renderer/platform/platform/iir_filter.o
Comment 1 Noel Bennett 2019-11-23 14:56:38 UTC
Created attachment 597154 [details]
Output of emerge --info
Comment 2 Chiitoo gentoo-dev 2019-11-23 20:04:48 UTC
Please try to make sure there are no heat or other hardware related problems (memtest might be a good idea), and that the machine isn't running out of RAM.

Using lower MAKEOPTS is also an idea, though yeah, it will take a lot more time...
Comment 3 Noel Bennett 2019-11-23 20:13:59 UTC
Tried using package.env to lower the MAKEOPTS on the build; maybe I managed to bugger it up, so I'll lower MAKEOPTS in make.conf. I'll keep an eye on the processor temp, too. If it fails again, I'll throw a memory test at it.

A hardware issue was my first bet, too, but it's occurring at the same spot on repeated builds, so...
Comment 4 Chiitoo gentoo-dev 2019-11-23 20:28:47 UTC
I did see '-j3' in the build log, and '-j5' in the '--info', so it may have worked.

I agree that the fact that it fails at the same spot each time is suspicious.
Comment 5 Noel Bennett 2019-11-24 01:02:18 UTC
Rerunning the build now; takes its sweet time on this old(er) laptop. Coretemps are sitting about 62 degrees Celsius and holding steady. I'll wait 'til it fails again, then I'll give the memory a test.
Comment 6 Daniel Nelson 2019-11-24 02:33:25 UTC
I'm also experiencing the same build error compiling this object file.
Comment 7 Scott Alfter 2019-11-26 07:09:49 UTC
Same error here, even with MAKEOPTS=-j1 and ccache disabled.  With 16 GB of RAM, I should be a long way from running out...right?
Comment 8 Chiitoo gentoo-dev 2019-11-26 13:22:17 UTC
Once is happenstance, twice is coincidence... three times is a bug!?

(In reply to Scott Alfter from comment #7)
> Same error here, even with MAKEOPTS=-j1 and ccache disabled.  With 16 GB of
> RAM, I should be a long way from running out...right?

With 16 GB, one should be able to go up to around '-j10'.  Perhaps a bit higher with USE="-jumbo-build".

I just ran a build in my stable testing environment, and did not manage to hit this.

I don't know if it will matter, but are you all using similar hardware?  The one in the 'emerge --info' we have here is different from mine, being an Intel i5 4200U while I'm with an AMD Ryzen 7 1700.  Will test with a Phenom II later today maybe.
Comment 9 Noel Bennett 2019-11-26 19:25:53 UTC
My desktop build is running an i7-4790k. I'll give it a go tonight.
Comment 10 Scott Alfter 2019-11-26 21:15:24 UTC
The home desktop (the one with trouble) is a Core i5 4690K.  After a few attempts, I gave up and am now trying to build v5.13.2 instead (which triggered a bunch of other upgrades that needed keywording).  This might end up being the better approach.

The upgrade process that kicked off this error included an upgrade to gcc 9 from gcc 8.  Might that have something to do with it?  I have some Raspberry Pi 3s running 64-bit Gentoo, and the switch from gcc 8 to 9 coincided with Python deciding to start segfaulting on certain types of network access (couldn't get OctoPrint or Certbot running properly).
Comment 11 Scott Alfter 2019-11-27 02:56:07 UTC
...and upgrading to 5.13.2 didn't change anything, other than that more source got compiled before the compile crapped itself.  It's even on the same bit of code:

[24216/25903] /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -MMD -MF obj/third_party/blink/renderer/platform/platform/push_pull_fifo.o.d -DUSE_FUNCTION_CITYHASH -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DNO_TCMALLOC -DOFFICIAL_BUILD -DCHROMIUM_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DBLINK_IMPLEMENTATION=1 -DINSIDE_BLINK -DBLINK_PLATFORM_IMPLEMENTATION=1 -DVK_NO_PROTOTYPES -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DWTF_USE_WEBAUDIO_FFMPEG=1 -DSUPPORT_WEBGL2_COMPUTE_CONTEXT=1 -DWTF_USE_DEFAULT_RENDER_THEME=1 -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_VULKAN_HEADER=\"../../skia/config/SkVulkanConfig.h\" -DSK_VULKAN=1 -DSK_SUPPORT_GPU=1 -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DVK_NO_PROTOTYPES -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DV8_DEPRECATION_WARNINGS -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX -DABSL_ALLOCATOR_NOTHROW=1 -DNO_MAIN_THREAD_WRAPPING -DLEVELDB_PLATFORM_CHROMIUM=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DUSE_SYSTEM_LIBJPEG -DV8_DEPRECATION_WARNINGS -I../../3rdparty/chromium/third_party/ffmpeg -Igen -I../../3rdparty/chromium -Igen -Igen -Igen -Igen -Igen -Igen -Igen -I../../3rdparty/chromium/third_party/khronos -I../../3rdparty/chromium/gpu -I../../3rdparty/chromium/third_party/vulkan/include -I../../3rdparty/chromium/third_party/libyuv/include -Igen -Igen -Igen -Igen -Igen -Igen -Igen -Igen -I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/skia/ext -I../../3rdparty/chromium/third_party/skia/include/c -I../../3rdparty/chromium/third_party/skia/include/config -I../../3rdparty/chromium/third_party/skia/include/core -I../../3rdparty/chromium/third_party/skia/include/docs -I../../3rdparty/chromium/third_party/skia/include/effects -I../../3rdparty/chromium/third_party/skia/include/encode -I../../3rdparty/chromium/third_party/skia/include/gpu -I../../3rdparty/chromium/third_party/skia/include/pathops -I../../3rdparty/chromium/third_party/skia/include/ports -I../../3rdparty/chromium/third_party/skia/include/utils -I../../3rdparty/chromium/third_party/vulkan/include -I../../3rdparty/cinclude/ports -I../../3rdparty/chromium/third_party/skia/include/utils -I../../3
rdparty/chromium/third_party/vulkan/include -I../../3rdparty/chromium/third_part
y/skia/third_party/vulkanmemoryallocator -I../../3rdparty/chromium/third_party/s
kia/include/codec -I../../3rdparty/chromium/third_party/skia/src/gpu -I../../3rd
party/chromium/third_party/skia/src/sksl -I../../3rdparty/chromium/third_party/s
kia/modules/skottie/include -I../../3rdparty/chromium/third_party/vulkan/include
 -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../3rd
party/chromium/third_party/protobuf/src -I../../3rdparty/chromium/third_party/bo
ringssl/src/include -I../../3rdparty/chromium/v8/include -Igen/v8/include -I../.
./3rdparty/chromium/third_party/ced/src -I../../3rdparty/chromium/third_party/we
brtc_overrides -I../../3rdparty/chromium/third_party/webrtc -Igen/third_party/we
brtc -I../../3rdparty/chromium/third_party/abseil-cpp -I../../3rdparty/chromium/
third_party/libwebm/source -I../../3rdparty/chromium/third_party/leveldatabase -
I../../3rdparty/chromium/third_party/leveldatabase/src -I../../3rdparty/chromium
/third_party/leveldatabase/src/include -I../../3rdparty/chromium/third_party/icc
jpeg -I../../3rdparty/chromium/third_party/ots/include -I../../3rdparty/chromium
/v8/include -Igen/v8/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fst
ack-protector -funwind-tables -fPIC -pipe -pthread -m64 -Wall -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-dep
recated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-dangling
-else -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-unused-parame
ter -fno-omit-frame-pointer -fvisibility=hidden -g0 -O2 -fno-ident -fdata-sectio
ns -ffunction-sections -I/usr/include/nss -I/usr/include/nspr -I/usr/include/lib
png16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -
I/usr/lib64/glib-2.0/include -std=gnu++14 -Wno-narrowing -Wno-attributes -Wno-cl
ass-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -fno-exceptions -fno-
rtti -fvisibility-inlines-hidden -c ../../3rdparty/chromium/third_party/blink/re
nderer/platform/audio/iir_filter.cc -o obj/third_party/blink/renderer/platform/p
latform/iir_filter.o
/var/tmp/portage/dev-libs/mpfr-3.1.6/work/mpfr-3.1.6/src/init2.c:52: MPFR assert
ion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: fre
../../3rdparty/chromium/third_party/blink/renderer/platform/audio/iir_filter.cc:
 In member function ‘void blink::IIRFilter::GetFrequencyResponse(int, const floa
t*, float*, float*)’:
../../3rdparty/chromium/third_party/blink/renderer/platform/audio/iir_filter.cc:
230:1: internal compiler error: Aborted
 }  // namespace blink
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
Comment 12 Chiitoo gentoo-dev 2019-11-27 04:17:00 UTC
Hmm, 'mpfr-3.1.6'...

Does '4.0.2' make any difference?
Comment 13 Scott Alfter 2019-11-27 05:21:45 UTC
Tried with USE=jumbo-build...same error.  There's something in iir_filter.cc that the compiler really doesn't like.

I thought I was compiling with gcc 9, but gcc 8 was still active (haven't yet run emerge --depclean).  Trying one more time with gcc 9...
Comment 14 Scott Alfter 2019-11-27 05:22:46 UTC
(In reply to Chiitoo from comment #12)
> Hmm, 'mpfr-3.1.6'...
> 
> Does '4.0.2' make any difference?

I noticed that...checked, and 4.0.2 is what I have installed.  I don't know where it's getting 3.1.6.  In-tree copy, perhaps?
Comment 15 Noel Bennett 2019-11-27 11:42:32 UTC
(In reply to Noel Bennett from comment #9)
> My desktop build is running an i7-4790k. I'll give it a go tonight.

Failed in the same spot as the original laptop.
Comment 16 Scott Alfter 2019-11-27 15:14:31 UTC
The dev-qt/qtwebengine-5.13.2 build finally succeeded when I switched from gcc 8 to 9.  I suspect qtwebengine-5.12.5 will also build properly under gcc 9.
Comment 17 Noel Bennett 2019-11-27 15:48:41 UTC
(In reply to Scott Alfter from comment #16)
> I suspect qtwebengine-5.12.5 will also build properly under gcc
> 9.

I'll give it a go this afternoon on both systems. Thanks for the work!
Comment 18 Chiitoo gentoo-dev 2019-11-27 19:22:40 UTC
(In reply to Scott Alfter from comment #14)
> (In reply to Chiitoo from comment #12)
> > Hmm, 'mpfr-3.1.6'...
> > 
> > Does '4.0.2' make any difference?
> 
> I noticed that...checked, and 4.0.2 is what I have installed.  I don't know
> where it's getting 3.1.6.  In-tree copy, perhaps?

Thought so, since it's stable.  Maybe it's coming from something built against 3.1.6 still (GCC 8?).

I have seen some reports of issues like this with GCC 8, but they're all quite different in the end.

Not sure how much we care though, since GCC 9 is also in stable.

I tried building with GCC 8.3.0-r1, which succeeded, but I did not try building GCC with 'mpfr-3.1.6' first...
Comment 19 Noel Bennett 2019-11-28 00:38:42 UTC
(In reply to Scott Alfter from comment #16)
> The dev-qt/qtwebengine-5.13.2 build finally succeeded when I switched from
> gcc 8 to 9.  I suspect qtwebengine-5.12.5 will also build properly under gcc
> 9.

Confirmed. Built fine on my desktop, using GCC 9. I failed to start the build on the laptop before walking away, but I suspect it'll be fine. I'll check in the morn.
Comment 20 Daniel Nelson 2019-11-29 03:02:50 UTC
I had the mpfr-3.1.6 bit in my build log as well, but 4.0.2 is installed.  I rebuilt gcc-8.3.0 and was then able to compile qtwebengine without error.
Comment 21 Chiitoo gentoo-dev 2019-11-29 04:14:31 UTC
(In reply to Daniel Nelson from comment #20)
> I had the mpfr-3.1.6 bit in my build log as well, but 4.0.2 is installed.  I
> rebuilt gcc-8.3.0 and was then able to compile qtwebengine without error.

I had the feeling that might do it.

Thanks for testing!
Comment 22 Rick Foland 2020-04-09 20:53:05 UTC
(In reply to Scott Alfter from comment #16)
> The dev-qt/qtwebengine-5.13.2 build finally succeeded when I switched from
> gcc 8 to 9.  I suspect qtwebengine-5.12.5 will also build properly under gcc
> 9.

Thank you so much! I didn't even realize that I hadn't switched from 8 to 9. 5.13.2 finally compiled for me after switching.
Comment 23 Chiitoo gentoo-dev 2020-04-09 21:11:08 UTC
Thank you all again!

I'll close this now, hoping it's rare enough for people to hit this at this point, with 'dev-libs/mpfr-4.0.2' being the only version in the official Gentoo ebuild repository and all that.
Comment 24 grsch 2020-04-22 08:38:28 UTC
Wouldn't it make sense to fix the issue by introducing a dependency to gcc9 into the .ebuild? 

I was one of the unlucky stumbling into it - since compile time on my laptop was rather long, and it took a couple of attempts, before I figured the trick, it took me about a day to get around it...

Either way, I think that if it doesn't compile with gcc8, a dependency to >=gcc-9 would be in order, wouldn't it? ;)
Comment 25 Chiitoo gentoo-dev 2020-04-22 11:40:20 UTC
As far as I understand the issue here, it's not about requiring GCC 9, but instead, having to recompile GCC after updating from 'mpfr-3.1.6' to 'mpfr-4.0.2' (for example).

If you're not seeing references to 3.1.6 while having 4.0.2 installed like the others here did, it could be a different problem.

If there was a simple way to fix this, it most likely would be implemented.  :]

I can only hope that no one else will suffer from this in the future.
Comment 26 nikarul 2020-10-03 15:47:20 UTC
FYI, I ran into this bug as well.  Rebuilding gcc 9.3.0 fixed it, just wanted to document that this is still happening out there in the wild.