use MinGW-w64 v3.1.0 for TBB 4.x

As discussed during the 13-Jun-2014 TBB dev meeting, I propose that we upgrade to MinGW-w64 v3.1.0 (latest stable version) for the TBB 4.x series. Doing so resolves some build issues with the Firefox updater code and will (hopefully) make things easier when we start to use ESR 31 code.

The newer MinGW also requires newer versions of gcc and binutils. I did a test build with gcc 4.8.3 (latest stable 4.8.x version) and binutils 2.24 (latest stable version). I did not notice any obvious problems.

brade and I will make our build changes available on a branch so that Mike and/or GK can review.

added MikePerry201406R component::applications/tor bundles/installation owner::erinn priority::medium resolution::fixed status::closed type::defect labels

OK, the branch is bug12406 within /user/brade/tor-browser-bundle.git, i.e., https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/shortlog/refs/heads/bug12406

We pushed two commits there. The first one (9b8fe357886ce56c5465641d15842492b10f72ec) is optional (it just cleans up a few tags, etc. within the versions.alpha and versions.nightly files). Note that we did not update versions.beta because it seems fairly out of date; I guess someone will just copy versions.alpha over versions.beta when the time is right.

The second commit (78a5e73d4e32334cca387be13b631687deeb0ec5) has the changes necessary for this bug. We changed the checkout_mingw() function within fetch-inputs.sh to support pulling via a tag and we updated the component versions. Again, we did not touch versions.beta.

The new version of gcc was signed by a different person, so we replaced the GCC keyring (I am not 100% sure how to do that in a secure way though). For the MINGW_HASH we just calculated a new value locally after pulling v3.1.0 using svn.

Trac:
Keywords: N/A deleted, MikePerry201406R added

Replying to mcs:

OK, the branch is bug12406 within /user/brade/tor-browser-bundle.git, i.e., https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/shortlog/refs/heads/bug12406

We pushed two commits there. The first one (9b8fe357886ce56c5465641d15842492b10f72ec) is optional (it just cleans up a few tags, etc. within the versions.alpha and versions.nightly files). Note that we did not update versions.beta because it seems fairly out of date; I guess someone will just copy versions.alpha over versions.beta when the time is right.

Yes, and update the missing things in versions.alpha (like bump to latest tor alpha, HTTPS-E version etc.). So, no worries here.

The second commit (78a5e73d4e32334cca387be13b631687deeb0ec5) has the changes necessary for this bug. We changed the checkout_mingw() function within fetch-inputs.sh to support pulling via a tag and we updated the component versions. Again, we did not touch versions.beta.

Why is the change in fetch-inputs.sh necessary? I mean what does speak against just bumping MINGW_VER to 6638 (which v3.1.0 is pointing to IIRC)? I don't see the benefit of having the additional complexity as tags in subversion can't be signed anyway (AFAICT).

Replying to gk:

Why is the change in fetch-inputs.sh necessary? I mean what does speak against just bumping MINGW_VER to 6638 (which v3.1.0 is pointing to IIRC)? I don't see the benefit of having the additional complexity as tags in subversion can't be signed anyway (AFAICT).

My SVN knowledge is very limited. It just seemed better to use a symbolic tag, but we can stick with SVN revisions if you prefer. But – and maybe I am misunderstanding svn revisions – isn't v3.1.0 revision 6434? Actually, digging a little deeper it looks like the MinGW-w64 project recently switched to git. The git hash for v3.1.0 seems to be 9418eaa1854320b57f40e29ec5bbc4f5717ecd58. Should we pull via git?

Replying to mcs:

Replying to gk:

Why is the change in fetch-inputs.sh necessary? I mean what does speak against just bumping MINGW_VER to 6638 (which v3.1.0 is pointing to IIRC)? I don't see the benefit of having the additional complexity as tags in subversion can't be signed anyway (AFAICT).

My SVN knowledge is very limited. It just seemed better to use a symbolic tag, but we can stick with SVN revisions if you prefer. But – and maybe I am misunderstanding svn revisions – isn't v3.1.0 revision 6434?

Maybe? :) I get checked out rev 6638 if I am running your branch. |svn update| in the mingw-w64 dir tells me I am already at rev 6638. But you might be right though. I guess rev 6638 is just the tag pointing to rev 6434...

Actually, digging a little deeper it looks like the MinGW-w64 project recently switched to git. The git hash for v3.1.0 seems to be 9418eaa1854320b57f40e29ec5bbc4f5717ecd58. Should we pull via git?

Sounds good. We could then get rid of the mingw-w64 SVN checkout related code, I guess. Not sure if they sign their tags. If not, just pin the commit we use (who knows where the tag is pointing to...).

The SVN developers did not create a signed tag for v3.0.1 so I just used the corresponding commit hash.

The new branch is bug12406-02 within /user/brade/tor-browser-bundle.git, i.e., https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/shortlog/refs/heads/bug12406-02

As before, the most recent two commits are the ones to look at.

Switching to git for MinGW-w64 was a little tricky because we build into a directory named mingw-w64 which conflicts with the "natural" directory that git would clone into. The solution we adopted is to clone into mingw-w64-git and keep everything else the same. To do that we had to tweak update_git() within fetch-inputs.sh to clone into the configured dir.

Please review. One question: is it sufficient to just check_git_hash() for MinGW-w64? (see our changes inside verify-tags.sh)

Replying to mcs:

The SVN developers did not create a signed tag for v3.0.1 so I just used the corresponding commit hash.

The new branch is bug12406-02 within /user/brade/tor-browser-bundle.git, i.e., https://gitweb.torproject.org/user/brade/tor-browser-bundle.git/shortlog/refs/heads/bug12406-02

As before, the most recent two commits are the ones to look at.

Switching to git for MinGW-w64 was a little tricky because we build into a directory named mingw-w64 which conflicts with the "natural" directory that git would clone into. The solution we adopted is to clone into mingw-w64-git and keep everything else the same. To do that we had to tweak update_git() within fetch-inputs.sh to clone into the configured dir.

Yes, having this explicit when cloning is even better. (Especially if one uses that directory later to check for something as we do).

Please review. One question: is it sufficient to just check_git_hash() for MinGW-w64? (see our changes inside verify-tags.sh)

Yes.

Thanks. Merged in commit 24677e9dad9092ba9fdaff751aef37b9ad3953e1.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed