Created attachment 461824 [details] compressed build.log the compilation of firefox fails at /var/tmp/portage/www-client/firefox-52.0_beta1/work/firefox-52.0b1/gfx/skia/skia/src/gpu/gl/GrGLUniformHandler.cpp with the following error In file included from /var/tmp/portage/www-client/firefox-52.0_beta1/work/firefox-52.0b1/ff/mozilla-config.h:214:0, from <command-line>:0: /var/tmp/portage/www-client/firefox-52.0_beta1/work/firefox-52.0b1/extensions/spellcheck/hunspell/glue/hunspell_alloc_hooks.h:54:74: error: no 'void* HunspellAllocator::CountingCalloc(size_t, size_t)' member function declared in class 'HunspellAllocator' #define calloc(count, size) HunspellAllocator::CountingCalloc(count, size) ^ /var/tmp/portage/www-client/firefox-52.0_beta1/work/firefox-52.0b1/extensions/spellcheck/hunspell/glue/hunspell_alloc_hooks.h:55:54: error: no 'void HunspellAllocator::CountingFree(void*)' member function declared in class 'HunspellAllocator' #define free(ptr) HunspellAllocator::CountingFree(ptr) I have the full build log attached. build options are emerge -pqv '=www-client/firefox-52.0_beta1::mozilla' [ebuild U ] www-client/firefox-52.0_beta1 [51.0] USE="dbus gtk2 jemalloc skia system-harfbuzz system-icu system-jpeg (system-libevent) system-libvpx system-sqlite -bindist -custom-cflags -custom-optimization -debug -gmp-autoupdate (-hardened) -hwaccel -jack (-neon) (-pgo) -pulseaudio (-rust) (-selinux) -startup-notification (-system-cairo) {-test} -wifi" L10N="(-ach%) (-af%) (-an%) (-ar%) (-as%) (-ast%) (-az%) (-bg%) (-bn-BD%) (-bn-IN%) (-br%) (-bs%) (-ca%) (-cak%) (-cs%) (-cy%) (-da%) (-de%*) (-dsb%) (-el%) (-en-GB%) (-en-ZA%) (-eo%) (-es-AR%) (-es-CL%) (-es-ES%) (-es-MX%) (-et%) (-eu%) (-fa%) (-ff%) (-fi%) (-fr%) (-fy%) (-ga%) (-gd%) (-gl%) (-gn%) (-gu%) (-he%) (-hi%) (-hr%) (-hsb%) (-hu%) (-hy%) (-id%) (-is%) (-it%) (-ja%) (-ka%) (-kab%) (-kk%) (-km%) (-kn%) (-ko%) (-lij%) (-lt%) (-lv%) (-mai%) (-mk%) (-ml%) (-mr%) (-ms%) (-nb%) (-nl%) (-nn%) (-or%) (-pa%) (-pl%) (-pt-BR%) (-pt-PT%) (-rm%) (-ro%) (-ru%) (-si%) (-sk%) (-sl%) (-son%) (-sq%) (-sr%) (-sv%) (-ta%) (-te%) (-th%) (-tr%) (-uk%) (-uz%) (-vi%) (-xh%) (-zh-CN%) (-zh-TW%)" firefox-51.0 used to build just fine with exactly the same useflags P.S. I upgraded harfbuzz to 1.4.2 because the build script requested at least 1.3.3, so the mozconfig eclass should reflect this. But I don't think this problem has been introduced by these changes!
Created attachment 461826 [details] output of emerge --info recent emerge --info
Any update on this? I'm seeing this on firefox-52.0_beta8::mozilla building against musl. Not certain why extensions/spellcheck/hunspell/glue/mozHunspellAllocator.h is not picking up those prototypes from xpcom/base/CountingAllocatorBase.h.
Corection: should be picked up from ff/dist/include/mozilla/CountingAllocatorBase.h
I don't really know what is going on here and how this mess was created in the first place. But it seems to be related to skia and with 52.0 skia seems to be mandantory and not an option anymore. Or maybe there is a problem with the patch of hunspell from the musl overlay? Will test again when the ebuild for 52.0 hits either the tree or the overlay.
*** Bug 613430 has been marked as a duplicate of this bug. ***
Created attachment 467878 [details, diff] fixes build Here's a patch that I quickly hacked together in order to fix the build. The issue is caused by `system-hunspell` being removed from USE. Reposted from https://bugs.gentoo.org/613430
(In reply to Aric Belsito from comment #6) > Created attachment 467878 [details, diff] [details, diff] > fixes build > > Here's a patch that I quickly hacked together in order to fix the build. The > issue is caused by `system-hunspell` being removed from USE. > > Reposted from https://bugs.gentoo.org/613430 So the system-hunspell flag was dropped because we force firefox to always build against system hunspell, not the other way around: [Quote mozconfig-v6.52.eclass]: > mozconfig_annotate 'Gentoo default' --enable-system-hunspell I think the issue may instead be that HUNSPELL_STATIC is being set regardless of whether firefox has been configured to use system-hunspell, since neither of those includes should be..um..included with the configuration gentoo forces. Marking this as confirmed since multiple musl users are hitting it.
(In reply to Ian Stakenvicius from comment #7) > (In reply to Aric Belsito from comment #6) > > Created attachment 467878 [details, diff] [details, diff] [details, diff] > > fixes build > > > > Here's a patch that I quickly hacked together in order to fix the build. The > > issue is caused by `system-hunspell` being removed from USE. > > > > Reposted from https://bugs.gentoo.org/613430 > > So the system-hunspell flag was dropped because we force firefox to always > build against system hunspell, not the other way around: > > [Quote mozconfig-v6.52.eclass]: > > mozconfig_annotate 'Gentoo default' --enable-system-hunspell > > I think the issue may instead be that HUNSPELL_STATIC is being set > regardless of whether firefox has been configured to use system-hunspell, > since neither of those includes should be..um..included with the > configuration gentoo forces. > > Marking this as confirmed since multiple musl users are hitting it. Ok so I did a bunch of investigation, and I cna't find anything that would indicate a bad change to the code to make it cause this. HOWEVER, I also can't seem to find anything that would indicate that re-#define'ing malloc() et. al. like this would be a good idea globall either, since there doesn't seem to be anything that keeps this (re)definition limited to hunspell. So I'm going to apply it anyways.
(In reply to Ian Stakenvicius from comment #8) > (In reply to Ian Stakenvicius from comment #7) > > (In reply to Aric Belsito from comment #6) > > > Created attachment 467878 [details, diff] [details, diff] [details, diff] [details, diff] > > > fixes build > > > > > > Here's a patch that I quickly hacked together in order to fix the build. The > > > issue is caused by `system-hunspell` being removed from USE. > > > > > > Reposted from https://bugs.gentoo.org/613430 > > > > So the system-hunspell flag was dropped because we force firefox to always > > build against system hunspell, not the other way around: > > > > [Quote mozconfig-v6.52.eclass]: > > > mozconfig_annotate 'Gentoo default' --enable-system-hunspell > > > > I think the issue may instead be that HUNSPELL_STATIC is being set > > regardless of whether firefox has been configured to use system-hunspell, > > since neither of those includes should be..um..included with the > > configuration gentoo forces. > > > > Marking this as confirmed since multiple musl users are hitting it. > > Ok so I did a bunch of investigation, and I cna't find anything that would > indicate a bad change to the code to make it cause this. > > HOWEVER, I also can't seem to find anything that would indicate that > re-#define'ing malloc() et. al. like this would be a good idea globall > either, since there doesn't seem to be anything that keeps this > (re)definition limited to hunspell. So I'm going to apply it anyways. Actually sorry I won't be, at least not as-is, since my understanding of how this works was wrong. I am still working on the proper solution though.
The patch of #613430 just works for me using GCC 5.4.0 and musl 1.1.16. Please apply if there is no serious reason to hold back.
Indeed, I tested normal build and debug build, both compile fine and there are no runtime issues.
Created attachment 469146 [details, diff] thunderbird-52.0 patch commenting calloc() and free() redefines Having the same issue now with thunderbird-52.0. Attaching the patch I'm using as a workaround. No noticeable runtime issues, though likely that hunspell memory reporting is significantly compromised.
Created attachment 469148 [details, diff] firefox-52.0 patch commenting calloc() and free() redefines And the same patch for Firefox.
(In reply to Nicholas Fish from comment #13) > Created attachment 469148 [details, diff] [details, diff] > firefox-52.0 patch commenting calloc() and free() redefines > > And the same patch for Firefox. I'm going to use this one, upstrean hasn't been able to help at all finding the root cause of this right now so I don't have any alternatives. All this does is provide support to about:memory auditing, apparently, so it shouldn't be horrible to have it disabled. I may make this conditionally applied based on when glibc is not the libc though, to retain upstream funcitonality as much as possible.
If there is an upstream bug report can you provide the link please? The patch is in the tree now but it does not apply conditionally on musl only, I assume you do have a reason for this?
(In reply to tt_1 from comment #15) > If there is an upstream bug report can you provide the link please? The > patch is in the tree now but it does not apply conditionally on musl only, I > assume you do have a reason for this? I don't have an upstream bug report, no. I decided against making it conditional on musl because the issue may occur on other alternate libc's as well (ie uclibc which iirc is making a comeback), and since all those wrappers do is support about:memory, which is a debug-info report for upstream to use with upstream's builds, it's not hugely useful for gentoo-built firefox anyways.
Has been addressed, was readdressed and will include new updated patchset with firefox-52.3 when released.
