Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#9830 closed defect (fixed)

mingw-w64 compilation of Firefox 24 ESR is broken

Reported by: gk Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: tbb-3.0, ff24-esr, MikePerry201311R
Cc: Actual Points:
Parent ID: #10103 Points:
Reviewer: Sponsor:

Description

mingw-w64 compilation of Firefox 24 ESR with the current rev (5830) is broken.

Child Tickets

Attachments (1)

0001-bump-mingw-w64-version-to-fix-compile-issue-with-Fir.patch (2.7 KB) - added by gk 7 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 7 years ago by gk

There are two types of bugs here: a) bugs mingw-w64 has itself and b) bugs due to compiling with mingw is no high priority of Mozilla. I already encountered both: We need at least rev 5880 to build Firefox 24 ESR (not sure yet if that is the revision we should use, probably not) and there are at least two bugs belonging to camp b). Fortunately it seems there is already someone (Jacek Caban) that paved the way here and that did all the patching for us (alas his patches missed the ESR24 train). He is quite helpful on IRC.

comment:2 Changed 7 years ago by gk

Status: newneeds_review

https://hg.mozilla.org/mozilla-central/rev/7b86302ab2b3
https://hg.mozilla.org/mozilla-central/rev/1651ea86cb00
https://hg.mozilla.org/mozilla-central/rev/fda0046aa376
https://hg.mozilla.org/mozilla-central/rev/02d4ae55e1c3

need to get merged in order to fix the breakage due to mingw-w64 being no tier-1 compiler for Mozilla. The last changeset might even be relevant for the TBB 2.x series (if it ever ships a Firefox 24) as I don't have a clue (and Jacek neither) how Firefox 24 could ever get built for Windows without it (maybe some MSVC, well, feature...).

The attached file fixes the mingw-w64 "internal" error as rev 5830 is not sufficient anymore to build ESR 24. We need at least 5880. I chose 6184 for the following reasons: 1) I built a lot with that revision when trying to solve the _strcmpi issue in #9084 and never had an issue. Thus, it is pretty stable. 2) rev 6184 contains the fix for the _strcmpi issue. Thus, if that one is indeed just an issue in our setup it can be solved without bumping the mingw-w64 revision again (assuming we would chose, say 5880, for resolving this bug). Granted, every rev > 6184 would be fit for this purpose as well. But I have not tested any so far in order to check whether they build Firefox at all...

comment:3 Changed 7 years ago by mikeperry

gk - should I merge this and your other two fixes (#9837 and #9828)? Will they interfere in any way with the current 17.0.9 builds (other than making them slightly slower due to recompiling python)?

comment:4 in reply to:  3 Changed 7 years ago by gk

Replying to mikeperry:

gk - should I merge this and your other two fixes (#9837 and #9828)? Will they interfere in any way with the current 17.0.9 builds (other than making them slightly slower due to recompiling python)?

#9837 will break 17.0.x builds and while it is probably okay to merge the patch in this bug and in #9828 (I'll upload a better one shortly) it might be a good idea to not introduce new possible issues into the ESR 17 build process. Thus, I would like to have either a ESR 24 branch where the patches get merged or that we wait until we are sure we won't ship another TBB 3.0 with an ESR 17. The rebasing (if needed) should be not much of an issue.

comment:5 Changed 7 years ago by mikeperry

gk - do you have a github account or equivalent for such a branch, or should we see about making you a Tor LDAP account and a tor-hosted remote?

comment:6 in reply to:  5 Changed 7 years ago by gk

Replying to mikeperry:

gk - do you have a github account or equivalent for such a branch, or should we see about making you a Tor LDAP account and a tor-hosted remote?

No, I don't have an account on code hosting platforms as I don't trust them. The LDAP account thingy sounds fine to me although I am not sure how involved the process is to get one (it should, for instance, be possible for me to get e.g. Linus' signature on my new key). If that turns out to be too hard, though, and attaching/using patches is too tedious then I might be convinced in biting the code-hosting-platform-bullet. Code hosting platforms are not that important in my threat model to prevent me from getting things done.

comment:7 Changed 7 years ago by gk

Parent ID: #9827#10103

comment:8 Changed 7 years ago by mikeperry

Keywords: MikePerry201311R added

comment:9 Changed 7 years ago by gk

While testing my patches again I realized that they are obviously not enough for a functional build anymore. It turns out that Firefox is now built with -static-libgcc and -static-libstdc++ (see: https://bugzilla.mozilla.org/show_bug.cgi?id=831707) which is probably the reason for the issue I encounter. I'll check that tomorrow and add another patch fixing this problem (hopefully).

comment:10 Changed 7 years ago by mikeperry

Ok, well I pushed your first patch to my mikeperry/ff24-staging remote of tor-browser-bundle. That branch has some other mac + windows fixes in it that are probably useful to work off of/test.

Let me know if I should throw anything else on that remote branch.

comment:11 in reply to:  9 Changed 7 years ago by gk

Replying to gk:

While testing my patches again I realized that they are obviously not enough for a functional build anymore. It turns out that Firefox is now built with -static-libgcc and -static-libstdc++ (see: https://bugzilla.mozilla.org/show_bug.cgi?id=831707) which is probably the reason for the issue I encounter. I'll check that tomorrow and add another patch fixing this problem (hopefully).

That was not enough although the dependency on libstdc++ is now showing up again in the Dependency Walker. Maybe backing out https://bugzilla.mozilla.org/show_bug.cgi?id=876416 is needed additionally...

comment:12 Changed 7 years ago by gk

Status: needs_reviewneeds_revision

Ugh, that did not help either :-/ It seems that #9084 is the reason I did not encounter that earlier: Without it building ESR24 is fine (I worked on this bug when #9084 was not merged yet) but with it it is broken, *sigh*.

comment:13 in reply to:  10 Changed 7 years ago by gk

Status: needs_revisionneeds_review

Replying to mikeperry:

Ok, well I pushed your first patch to my mikeperry/ff24-staging remote of tor-browser-bundle. That branch has some other mac + windows fixes in it that are probably useful to work off of/test.

Let me know if I should throw anything else on that remote branch.

No, not yet. The only thing that needs to be done in this bug is merging the patches in comment 2 to tor-browser, then it can be closed. The problem I investigated in the last comments merits an own bug (which is #10252 now) as the compilation of ESR 24 is indeed fixed with the patches mentioned in/attached to this bug.

comment:14 Changed 7 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok. The patch from comment 2 is merged into origin/master.

comment:15 Changed 7 years ago by mikeperry

Did I miss something here? I merged the patch from comment 2. Was I also supposed to revert (or apply) one or more of those bugzilla patches too? That wasn't clear to me.

Note: See TracTickets for help on using tickets.