emerge firefox-52.4.0 compile failure

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

emerge firefox-52.4.0 compile failure

Grant Edwards-6
When I did my usual update today firefox 52.4.0 failed to build.
There are thousands of compiler warnings in the build log, but the
only thing I can find that looks like an error is this:

/usr/bin/x86_64-pc-linux-gnu-g++ [...] /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/thebes/Unified_cpp_gfx_thebes0.cpp
[...]
In file included from /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/thebes/Unified_cpp_gfx_thebes0.cpp:65:0:
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2625:29: error: 'mozilla::gfx::ShapedTextFlags' has not been declared
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2626:24: error: 'RoundingFlags' has not been declared
/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebes/gfxFont.cpp:2618:1: error: template-id 'GetShapedWord<>' for 'gfxShapedWord* gfxFont::GetShapedWord(gfxFont::DrawTarget*, const uint8_t*, uint32_t, uint32_t, gfxFont::Script, bool, int32_t, int, int, gfxTextPerfMetrics*)' does not match any template declaration
[...]
make[4]: *** [/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/config/rules.mk:951: Unified_cpp_gfx_thebes0.o] Error 1
make[4]: *** Waiting for unfinished jobs....

Google provides zero hits for any of those three errors.

Does this look familiar to anybody?

--
Grant







Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Mick-10
On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:

> When I did my usual update today firefox 52.4.0 failed to build.
> There are thousands of compiler warnings in the build log, but the
> only thing I can find that looks like an error is this:
>
> /usr/bin/x86_64-pc-linux-gnu-g++ [...]
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp [...]
> In file included from
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp:65:0:
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2625:29: error: 'mozilla::gfx::ShapedTextFlags' has not been
> declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2626:24: error: 'RoundingFlags' has not been declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2618:1: error: template-id 'GetShapedWord<>' for
> 'gfxShapedWord* gfxFont::GetShapedWord(gfxFont::DrawTarget*, const
> uint8_t*, uint32_t, uint32_t, gfxFont::Script, bool, int32_t, int, int,
> gfxTextPerfMetrics*)' does not match any template declaration [...]
> make[4]: ***
> [/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/config/r
> ules.mk:951: Unified_cpp_gfx_thebes0.o] Error 1 make[4]: *** Waiting for
> unfinished jobs....
>
> Google provides zero hits for any of those three errors.
>
> Does this look familiar to anybody?
>
> --
> Grant
Your compiler is barfing at something, but I'm no coder to know what this
might be.  In a Gentoo context, I'd start by checking you have installed and
switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at
least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-08, Mick <[hidden email]> wrote:
> On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
>> When I did my usual update today firefox 52.4.0 failed to build.
>> There are thousands of compiler warnings in the build log, but the
>> only thing I can find that looks like an error is this:

[...]

>> Google provides zero hits for any of those three errors.

> Your compiler is barfing at something, but I'm no coder to know what
> this might be.

Yes, thanks, those are g++ compiler error messages.  I could track
down and fix the problem in the source code, but since it's a "stable"
system, and firefox builds fine on other systems, I should have to do
that.

> In a Gentoo context, I'd start by checking you have installed and
> switched to sys-devel/gcc-5.4.0-r3

Yep, I'm using gcc-5.4.0-r3.  There were 20+ other packages that got
built in that same upgrade, and they all went fine.

> which is the latest stable version and at least here compiled and
> installed firefox-52.4.0 on 4 PCs without a problem.

As have I.

I was afraid it might be failing RAM, but a second attempt failed in
exactly the same way.  I guess I'll delete the ebuild files and the
source tarball to force a download and then try again.

--
Grant





Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Mick-10
On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:

> I was afraid it might be failing RAM, but a second attempt failed in
> exactly the same way.  I guess I'll delete the ebuild files and the
> source tarball to force a download and then try again.

This won't harm, although I would expect portage would complain and not run
the emerge if downloads were corrupted somehow.
--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-08, Mick <[hidden email]> wrote:
> On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:
>
>> I was afraid it might be failing RAM, but a second attempt failed in
>> exactly the same way.  I guess I'll delete the ebuild files and the
>> source tarball to force a download and then try again.

Same error.

> This won't harm, although I would expect portage would complain and
> not run the emerge if downloads were corrupted somehow.

True, but I couldn't think of anything else to try.  I'm building
chromium now -- it may be time to give up on firefox.  It's been
bahaving badly on several of my systems for a while now (burning 100%
cpu and using up huge amounts of RAM for minutes at a time while
apparently doing nothing).

--
Grant





Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

R0b0t1
On Sun, Oct 8, 2017 at 1:54 PM, Grant Edwards <[hidden email]> wrote:

> On 2017-10-08, Mick <[hidden email]> wrote:
>> This won't harm, although I would expect portage would complain and
>> not run the emerge if downloads were corrupted somehow.
>
> True, but I couldn't think of anything else to try.  I'm building
> chromium now -- it may be time to give up on firefox.  It's been
> bahaving badly on several of my systems for a while now (burning 100%
> cpu and using up huge amounts of RAM for minutes at a time while
> apparently doing nothing).
>

Usually what happens is it will be corrupted in RAM after being
verified on disk, and faulty results will be saved to disk from RAM. A
user on the forums recently had this issue compiling dev-lang/vala,
and I have had related issues.

As for what the error means: definitions are missing, which from an
end-user perspective is not really a fixable issue. I would rerun the
compilation with -j1 if you have not already done so. If other people
can build the package then portage may be munging the files in some
way, but these issues are hard to diagnose.

Cheers,
     R0b0t1

Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-08, R0b0t1 <[hidden email]> wrote:

> Usually what happens is it will be corrupted in RAM after being
> verified on disk, and faulty results will be saved to disk from RAM. A
> user on the forums recently had this issue compiling dev-lang/vala,
> and I have had related issues.

I've had failing RAM corrupt files and cause compile failures (and
various other odd problems). But, the exact symptoms tend to be pretty
random.  The chances are infinitesmal that a HW problem would corrupt
the download (or the compile itself) in an identical manner a second
time.

> As for what the error means: definitions are missing, which from an
> end-user perspective is not really a fixable issue.

Sometimes there are external library version/use-flag requirements
that don't make it into an ebuild file correctly.  But, all the other
cases I've run into like that yielded plenty of Google hits on the
error messages.

> I would rerun the compilation with -j1 if you have not already done
> so.

I'm going to try that as soon as chromium finishes building.

> If other people can build the package then portage may be munging the
> files in some way, but these issues are hard to diagnose.

--
Grant




Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

R0b0t1
On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards <[hidden email]> wrote:

> On 2017-10-08, R0b0t1 <[hidden email]> wrote:
>
>> Usually what happens is it will be corrupted in RAM after being
>> verified on disk, and faulty results will be saved to disk from RAM. A
>> user on the forums recently had this issue compiling dev-lang/vala,
>> and I have had related issues.
>
> I've had failing RAM corrupt files and cause compile failures (and
> various other odd problems). But, the exact symptoms tend to be pretty
> random.  The chances are infinitesmal that a HW problem would corrupt
> the download (or the compile itself) in an identical manner a second
> time.
>

Right, redownloading or rerunning the compilation usually fixes such
issues. At the same time, I have seen people hit bad areas of RAM
repeatedly and have it look like other errors.

>> As for what the error means: definitions are missing, which from an
>> end-user perspective is not really a fixable issue.
>
> Sometimes there are external library version/use-flag requirements
> that don't make it into an ebuild file correctly.  But, all the other
> cases I've run into like that yielded plenty of Google hits on the
> error messages.
>

In this case the namespace of the missing declaration is inside
Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Cheers,
    R0b0t1

Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-09, R0b0t1 <[hidden email]> wrote:

> In this case the namespace of the missing declaration is inside
> Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Yep, after a bit more research, that was my conclusion.

The chromium build finished happily, so I've just started another
firefox build with MAKEOPTS=-j1.  

The USE flag settings for firefox appear to be the same as my other
systems where it builds without error.

Weird.

--
Grant



Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-09, Grant Edwards <[hidden email]> wrote:
> On 2017-10-09, R0b0t1 <[hidden email]> wrote:
>
>> In this case the namespace of the missing declaration is inside
>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>
> Yep, after a bit more research, that was my conclusion.
>
> The chromium build finished happily, so I've just started another
> firefox build with MAKEOPTS=-j1.  

Same error.  But at least it's at the end of the build log now where
it's easy to find. :)

I guess I'll wait for the next firefox ESR update and see if that one
builds.

--
Grant





Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

allan gottlieb
On Mon, Oct 09 2017, Grant Edwards wrote:

> On 2017-10-09, Grant Edwards <[hidden email]> wrote:
>> On 2017-10-09, R0b0t1 <[hidden email]> wrote:
>>
>>> In this case the namespace of the missing declaration is inside
>>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>>
>> Yep, after a bit more research, that was my conclusion.
>>
>> The chromium build finished happily, so I've just started another
>> firefox build with MAKEOPTS=-j1.  
>
> Same error.  But at least it's at the end of the build log now where
> it's easy to find. :)
>
> I guess I'll wait for the next firefox ESR update and see if that one
> builds.

This is a know bug see https://bugs.gentoo.org/633790

allan

Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-09, allan gottlieb <[hidden email]> wrote:

> This is a know bug see https://bugs.gentoo.org/633790

Yep, that's it.  Yet when you search for roundingflags or
shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
search feature in Bugzilla ever worked?

--
Grant Edwards               grant.b.edwards        Yow! Four thousand
                                  at               different MAGNATES, MOGULS
                              gmail.com            & NABOBS are romping in my
                                                   gothic solarium!!


Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
In reply to this post by Mick-10
On 2017-10-08, Mick <[hidden email]> wrote:

> Your compiler is barfing at something, but I'm no coder to know what this
> might be.  In a Gentoo context, I'd start by checking you have installed and
> switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at
> least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

It turns out that over the past week or so, there have been several
_different_ firefox ebuilds released.  One of them was broken:

  Version 52.4.0 (Oct 3) was OK.

  Version 52.4.0 (Oct 7) was broken.

  Version 52.4.0 (Oct 9) is OK.

You (and I) had successfully installed the Oct 3 version of 52.4.0,
but when I tried to install the Oct 7 version of 52.4.0, it failed.
The Oct 9 version is supposed to be fixed. I don't really see how you
can repeatedly release new versions of something without changing the
version number, but maybe that's just me...

--
Grant Edwards               grant.b.edwards        Yow! Being a BALD HERO
                                  at               is almost as FESTIVE as a
                              gmail.com            TATTOOED KNOCKWURST.


Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

R0b0t1
In reply to this post by Grant Edwards-6
On Monday, October 9, 2017, Grant Edwards <[hidden email]> wrote:
> On 2017-10-09, allan gottlieb <[hidden email]> wrote:
>
>> This is a know bug see https://bugs.gentoo.org/633790
>
> Yep, that's it.  Yet when you search for roundingflags or
> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
> search feature in Bugzilla ever worked?
>

It's pretty limited. You might notice developers renaming bugs - this is why. They usually include the full package name and version in their rename, as well as the exact text from the last or most important error encountered.

I filed a bug against nvidia-drivers last night which was a duplicate of something that came up in the automatic search. It's hard to canvas the tracker exhaustively.

R0b0t1.
Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Grant Edwards-6
On 2017-10-09, R0b0t1 <[hidden email]> wrote:

> On Monday, October 9, 2017, Grant Edwards <[hidden email]> wrote:
>> On 2017-10-09, allan gottlieb <[hidden email]> wrote:
>>
>>> This is a know bug see https://bugs.gentoo.org/633790
>>
>> Yep, that's it.  Yet when you search for roundingflags or
>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>> search feature in Bugzilla ever worked?
>
> It's pretty limited.

You're being too kind.  It's broken.  According to the bugzilla web
page, the search includes the summary/description (as one might
expect), but it doesn't actually _do_ that.

> You might notice developers renaming bugs -
> this is why. They usually include the full package name and version
> in their rename, as well as the exact text from the last or most
> important error encountered.

Why do people still use bugzilla??

I've used MantisBT a lot over the past few years, and it seems like it
works much better than bugzilla in many ways. It even has a search
that works!  Even Jira was better than bugzilla, and I never liked
Jira much.

Of course switching from one bug tracking system to another is a
pretty big undertaking...

--
Grant




Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

R0b0t1
On Mon, Oct 9, 2017 at 7:57 PM, Grant Edwards <[hidden email]> wrote:

> On 2017-10-09, R0b0t1 <[hidden email]> wrote:
>> On Monday, October 9, 2017, Grant Edwards <[hidden email]> wrote:
>>> On 2017-10-09, allan gottlieb <[hidden email]> wrote:
>>>
>>>> This is a know bug see https://bugs.gentoo.org/633790
>>>
>>> Yep, that's it.  Yet when you search for roundingflags or
>>> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
>>> search feature in Bugzilla ever worked?
>>
>> It's pretty limited.
>
> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.
>

Well, it successfully searches for substrings.

>> You might notice developers renaming bugs -
>> this is why. They usually include the full package name and version
>> in their rename, as well as the exact text from the last or most
>> important error encountered.
>
> Why do people still use bugzilla??
>
> I've used MantisBT a lot over the past few years, and it seems like it
> works much better than bugzilla in many ways. It even has a search
> that works!  Even Jira was better than bugzilla, and I never liked
> Jira much.
>
> Of course switching from one bug tracking system to another is a
> pretty big undertaking...
>

I worked with a project that used Mantis and had a good experience
with it. At this point I'm not sure it would be possible to get people
to switch.

There are a few migration scripts:
http://www.mantisbt.org/wiki/doku.php/mantisbt:faq.

R0b0t1.

Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Peter Humphrey-3
In reply to this post by Grant Edwards-6
On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:

> I don't really see how you can repeatedly release new versions of
> something without changing the version number, but maybe that's just me...

No, it isn't just you. What you describe is a classic example of a developer
trying to hide his mistakes - strictly unprofessional. It would not have
been allowed anywhere I've worked.

I know that volunteers are hard to find, but even so ...

Good work spotting the trail, by the way.

--
Regards,
Peter.


Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Marc Joliet
Am Dienstag, 10. Oktober 2017, 11:19:02 CEST schrieb Peter Humphrey:

> On Monday, 9 October 2017 20:20:53 BST Grant Edwards wrote:
> > I don't really see how you can repeatedly release new versions of
> > something without changing the version number, but maybe that's just me...
>
> No, it isn't just you. What you describe is a classic example of a developer
> trying to hide his mistakes - strictly unprofessional. It would not have
> been allowed anywhere I've worked.
>
> I know that volunteers are hard to find, but even so ...
>
> Good work spotting the trail, by the way.
It's actually simpler than that: ebuilds do not need a revision bump when
fixing compilation errors, since the ebuild remains uninstalled [0].  And if
you /were/ able to build it, you won't profit from a revbump, either (in fact,
people tend to loudly complain about unnecessary rebuilds).  So, no, it most
likely is /not/ someone trying to hide their mistakes.  Never mind that the
changes are easy to find in Gentoo's version control history [1], which
references bug #633640, which in turn reveals that they were trying to fix a
build error, but accidentally caused another in the process.  So, yeah, so
much hiding going on here!

[0] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/
[1] https://gitweb.gentoo.org/repo/gentoo.git/log/?qt=grep&q=firefox

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Marc Joliet
In reply to this post by Grant Edwards-6
Am Dienstag, 10. Oktober 2017, 02:57:21 CEST schrieb Grant Edwards:
> On 2017-10-09, R0b0t1 <[hidden email]> wrote:
> > On Monday, October 9, 2017, Grant Edwards <[hidden email]>
wrote:
> >> On 2017-10-09, allan gottlieb <[hidden email]> wrote:
> >>> This is a know bug see https://bugs.gentoo.org/633790
> >>
> >> Yep, that's it.  Yet when you search for roundingflags or
> >> shapedtextflags in Gentoo's bugzilla, it finds nothing.  Has the
> >> search feature in Bugzilla ever worked?
> >
> > It's pretty limited.

Do you still think so when you consider the advanced search (or the saved
search feature)?  Just curious, since I don't tend to perform complicated
searches in any of the bug trackers I use.

> You're being too kind.  It's broken.  According to the bugzilla web
> page, the search includes the summary/description (as one might
> expect), but it doesn't actually _do_ that.

It does exactly what it says, e.g., when I search for qt I see:

"     Status: UNCONFIRMED, CONFIRMED, IN_PROGRESS Alias: qt Summary: qt "

And it shows me exactly that: bugs with qt in the summary or as part of the
alias that have their status set to UNCONFIRMED, CONFIRMED, or IN_PROGRESS.  
(Note that it does *not* search the description by default, and doesn't claim
to, either!)

Now, it could be that other search filters are preventing you from finding
bugs.  For example, as in my above example, bugs with their status set to
"RESOLVED" or "VERIFIED" are not searched by default (searching only for
VERIFIED found 120 additional bugs).  Or, more likely, your search strings
simply aren't part of the summary.

Of course, it's not like I actively like bugzilla, but it's not quite
"broken", either.  "Baroque" might be a better word ;) .

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: emerge firefox-52.4.0 compile failure

Neil Bothwick
In reply to this post by Grant Edwards-6
On Mon, 9 Oct 2017 19:20:53 +0000 (UTC), Grant Edwards wrote:

> It turns out that over the past week or so, there have been several
> _different_ firefox ebuilds released.  One of them was broken:
>
>   Version 52.4.0 (Oct 3) was OK.
>
>   Version 52.4.0 (Oct 7) was broken.
>
>   Version 52.4.0 (Oct 9) is OK.
>
> You (and I) had successfully installed the Oct 3 version of 52.4.0,
> but when I tried to install the Oct 7 version of 52.4.0, it failed.
> The Oct 9 version is supposed to be fixed. I don't really see how you
> can repeatedly release new versions of something without changing the
> version number, but maybe that's just me...
It depends on the breakage. If the installed program is broken it should
be bumped, but if the breakage only relates to the build in some
circumstances, it makes sense not to bump it. Otherwise everyone that
installed the first time, maybe because they had the necessary
dependencies already, would have to re-emerge the package another two
times for no benefit.

If they truly were new versions it would be different, but all the ebuilds
resulted in the same version of the software being installed.


--
Neil Bothwick

Puns are bad, but poetry is verse...

attachment0 (849 bytes) Download Attachment
12