Upgrade Binutils to 2.25+ for Tor Browser builds
We tried to upgrade our toolchain during the transition to Tor Browser 5.0 but doing that for Binutils fails for various reasons. We should investigate these and fix them.
Activity
One issue that got fixed was timestamps not being zeroed out anymore in .dlls. For a reason why this happend see comment:10:ticket:16351ff. commit 1b5ae9017625081f251c71afb359bf9345c76b03 has a fix for it.
The other one resulted in differences in some Firefox related binaries and fte.cDFA.pyd. The diff of the latter between Mike's and my version is attached.
-
Trac:
ftediff.zip 
A patch that might fix the issue is this one from Debian, which is setting the timestamp using the SOURCE_DATE_EPOCH environment variable: https://anonscm.debian.org/cgit/collab-maint/binutils-mingw-w64.git/tree/debian/patches/specify-timestamp.patch
Our current patch is fixing the timestamp in bfd/peXXigen.c, while this patch also fix it in ld/pe-dll.c.
-
FWIW: Our patch got "upstreamed" with https://sourceware.org/bugzilla/show_bug.cgi?id=20634 which is available in binutils 2.28.
Trac:
Reviewer: N/A to N/A -
Trac:
Parent: N/A to #12968 (moved) -
After updating binutils to 2.30, the Linux x86_64 version builds fine, however the Linux i686 one fails while building firefox with:
+ exec /var/tmp/dist/gcc/bin/g++ -B/var/tmp/dist/selfrando/Tools/TorBrowser/tc-wrapper -ffunction-sections -fdata-sections -fPIC -std=gnu++11 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-lifetime-dse -m32 -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -Os -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libfakeopenh264.so -o libfakeopenh264.so /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/dom/media/gmp-plugin-openh264/tmpnYmh7y.list -lpthread -m32 -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -Wl,-rpath-link,/var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/dist/bin -Wl,-rpath-link,/usr/local/lib collect2: fatal error: ld terminated with signal 6 [Aborted] compilation terminated. /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-T5OaCF37Jw: relocation R_386_GOTOFF against preemptible symbol kLogStrings cannot be used when making a shared object Linker execution failed, status: 1 ld: src/Support/posix/Debug.cpp:36: void Error::printf(const char*, ...): Assertion `false' failed. make[5]: *** [libfakeopenh264.so] Error 1 make[5]: Leaving directory `/var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/dom/media/gmp-plugin-openh264' make[4]: *** [dom/media/gmp-plugin-openh264/target] Error 2 Replying to boklm:
After reverting commit ed700649d0607e6509d5bbc51f4617bbae13a543 from binutils, firefox builds without error on linux-i686. gold started to detect errors as ld. Why to revert that? Maybe, adding
staticto kLogStrings could help?-
Adding
staticto kLogStrings is indeed fixing the issue.The next error is:
+ exec /var/tmp/dist/gcc/bin/gcc -B/var/tmp/dist/selfrando/Tools/TorBrowser/tc-wrapper -ffunction-sections -fdata-sections -fPIC -m32 -std=gnu99 -shared -Wl,--gc-section s -Wl,-z,defs -Wl,-soname -Wl,libnssutil3.so -Wl,--version-script,/var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/nssutil.def -o /var/tmp /build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/libnssutil3.so /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/qu ickder.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secdig.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/ lib/util/derdec.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/derenc.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/secu rity/nss/lib/util/dersubr.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/dertime.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-lin ux-gnu/security/nss/lib/util/errstrs.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/nssb64d.o /var/tmp/build/firefox-017a7ad9488d/obj- i686-pc-linux-gnu/security/nss/lib/util/nssb64e.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/nssrwlk.o /var/tmp/build/firefox-017a7a d9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/nssilock.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/oidstring.o /var/tmp/build/ firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/pkcs1sig.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/portreg.o /va r/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secalgid.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/s ecasn1d.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secasn1e.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/n ss/lib/util/secasn1u.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secitem.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gn u/security/nss/lib/util/secload.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secoid.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-p c-linux-gnu/security/nss/lib/util/sectime.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/secport.o /var/tmp/build/firefox-017a7ad9488d /obj-i686-pc-linux-gnu/security/nss/lib/util/templates.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/utf8.o /var/tmp/build/firefox-01 7a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/utilmod.o /var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/utilpars.o -L/var/tmp/bu ild/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/dist/lib -L/var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/dist/bin -lplc4 -lplds4 -lnspr4 -lpthread -ldl -lc collect2: fatal error: ld terminated with signal 6 [Aborted] compilation terminated. /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.12' and 'NSSUTIL_3.12.3' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.12.3' and 'NSSUTIL_3.12.5' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.12.5' and 'NSSUTIL_3.12.7' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.12.7' and 'NSSUTIL_3.13' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.13' and 'NSSUTIL_3.14' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.14' and 'NSSUTIL_3.15' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.15' and 'NSSUTIL_3.17.1' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.17.1' and 'NSSUTIL_3.21' in script /var/tmp/dist/binutils/bin/ld.gold.real: warning: wildcard match appears in both version 'NSSUTIL_3.21' and 'NSSUTIL_3.24' in script /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-Dtc3WlhCcG: relocation R_386_GOTOFF against preemptible symbol SEC_SequenceOfObjectIDTemplate cannot be used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-Dtc3WlhCcG: relocation R_386_GOTOFF against preemptible symbol SEC_PointerToGeneralizedTimeTemplate cannot b e used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-Dtc3WlhCcG: relocation R_386_GOTOFF against preemptible symbol SEC_PointerToEnumeratedTemplate cannot be use d when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-Dtc3WlhCcG: relocation R_386_GOTOFF against preemptible symbol SEC_SequenceOfAnyTemplate cannot be used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-cDg6BKy5jw: relocation R_386_GOTOFF against preemptible symbol sgn_DigestInfoTemplate_Util cannot be used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-cDg6BKy5jw: relocation R_386_GOTOFF against preemptible symbol SEC_SetOfAnyTemplate_Util cannot be used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-cDg6BKy5jw: relocation R_386_GOTOFF against preemptible symbol SEC_PointerToOctetStringTemplate_Util cannot be used when making a shared object /var/tmp/dist/binutils/bin/ld.gold.real: error: /tmp/trapobj-cDg6BKy5jw: relocation R_386_GOTOFF against preemptible symbol SEC_PointerToAnyTemplate_Util cannot be used when making a shared object Linker execution failed, status: 1 ld: src/Support/posix/Debug.cpp:36: void Error::printf(const char*, ...): Assertion `false' failed. make[7]: *** [/var/tmp/build/firefox-017a7ad9488d/obj-i686-pc-linux-gnu/security/nss/lib/util/libnssutil3.so] Error 1 gold throws that error instead of generating (potentially exploitable?) code which leads to runtime segmentation fault instead of preemptible symbol (if it got preempted) in that case. Yes, this is how x86 Linux works. To put some light on it: https://software.intel.com/en-us/blogs/2010/11/10/limit-performance-impact-of-global-symbols-on-linux/ It seems, Linux developers are generally shocked and don't know what to do with it, even in Mozilla.
-
In branch
bug_16472_v2I added a commit updating binutils to 2.30: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v2&id=fd2706c19dad44730ef10f8d868ac965d84a65b7I also added a test commit adding two
tor-browser.gitpatches fixing the build, but I am not sure that they are correct: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v2&id=868c0384fa306f51f5be5e16a32b6ef063ade2a9However, after updating gcc to 6.4.0, it seems those two patches are not needed anymore (and make the build fail). So I think we should update both binutils and gcc at the same time.
-
Replying to boklm:
In branch
bug_16472_v2I added a commit updating binutils to 2.30: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v2&id=fd2706c19dad44730ef10f8d868ac965d84a65b7I also added a test commit adding two
tor-browser.gitpatches fixing the build, but I am not sure that they are correct: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v2&id=868c0384fa306f51f5be5e16a32b6ef063ade2a9However, after updating gcc to 6.4.0, it seems those two patches are not needed anymore (and make the build fail). So I think we should update both binutils and gcc at the same time.
Agreed, bumping both at the same time sounds like a good idea, especially if that means we don't need those additional patches.
Have you checked about the deterministic output of the Windows bundles after the switch to the newer binutils version? That has been the main reason for why an update did not happen earlier (see: comment:1).
-
Replying to boklm:
However, after updating gcc to 6.4.0, it seems those two patches are not needed anymore (and make the build fail). So I think we should update both binutils and gcc at the same time.
It seems I was wrong on that, I had been trying an x86_64 build instead of an i686 one, and on i686 the build still fails with gcc 6.4.0 with the same error as in comment:9.
-
Replying to gk:
Hm. Is that caused by Selfrando? I can't otherwise imagine we are the only ones hitting that while compiling Firefox given that binutils 2.27+ and GCC 6.4.0 is not an esoteric compiler/linker combo.
Yes, it seems to be caused by Selfrando. I started a build after disabling Selfrando, and the build did not fail in this case.
-
Replying to boklm:
Replying to gk:
Hm. Is that caused by Selfrando? I can't otherwise imagine we are the only ones hitting that while compiling Firefox given that binutils 2.27+ and GCC 6.4.0 is not an esoteric compiler/linker combo.
Yes, it seems to be caused by Selfrando. I started a build after disabling Selfrando, and the build did not fail in this case.
Okay, let me get back to the selfrando folks with that.
-
boklm: We are using an older tag for selfrando. Could you double-check that the issue is still there with the latest code on
master? That said I think it is fine dropping selfrando in a separate patch for this bug if that's the only issue blocking the binutils uprade, at least until it is fixed upstream (i.e. on selfrando's side). -
Replying to gk:
boklm: We are using an older tag for selfrando. Could you double-check that the issue is still there with the latest code on
master? That said I think it is fine dropping selfrando in a separate patch for this bug if that's the only issue blocking the binutils uprade, at least until it is fixed upstream (i.e. on selfrando's side).I tried a build using selfrando commit de95c99364214d631df01364e0e87e6b6c307eba (current master), and it also fails with the error from comment:9.
-
Replying to gk:
Have you checked about the deterministic output of the Windows bundles after the switch to the newer binutils version? That has been the main reason for why an update did not happen earlier (see: comment:1).
It seems it is not deterministic. I did two builds using branch
boklm/bug_16472_v3, and have some differences in the Windows builds. I will attach the output of diffoscope ontor-win32-0.3.3.2-alpha.zip. -
Trac:
tor-win32.diff -
Replying to gk:
boklm: could you test the selfrando commit d2951ac1d3747a4d8a9ef222d38d2d13e5ae2ba9 and report back whether that solved our problems? ahomescu said we should be good with that one.
It seems it fixed the previous error, however we now have a different error:
Executing /var/tmp/build/firefox-8ee6fdadea2a/obj-i686-pc-linux-gnu/dist/bin/shlibsign -v -o ../../dist/firefox/libsoftokn3.chk -i ../../dist/firefox/libsoftokn3.so Traceback (most recent call last): File "/var/tmp/build/firefox-8ee6fdadea2a/toolkit/mozapps/installer/packager.py", line 341, in <module> main() File "/var/tmp/build/firefox-8ee6fdadea2a/toolkit/mozapps/installer/packager.py", line 337, in main copier.copy(args.destination) File "/var/tmp/build/firefox-8ee6fdadea2a/python/mozbuild/mozpack/copier.py", line 399, in copy copy_results.append((destfile, f.copy(destfile, skip_if_older))) File "/var/tmp/build/firefox-8ee6fdadea2a/toolkit/mozapps/installer/packager.py", line 124, in copy errors.fatal('Error while signing %s' % self.path) File "/var/tmp/build/firefox-8ee6fdadea2a/python/mozbuild/mozpack/errors.py", line 103, in fatal self._handle(self.FATAL, msg) File "/var/tmp/build/firefox-8ee6fdadea2a/python/mozbuild/mozpack/errors.py", line 98, in _handle raise ErrorMessage(msg) mozpack.errors.ErrorMessage: Error: Error while signing ../../dist/firefox/libsoftokn3.so make[3]: *** [stage-package] Error 1 make[3]: Leaving directory `/var/tmp/build/firefox-8ee6fdadea2a/obj-i686-pc-linux-gnu/browser/installer' -
Replying to gk:
boklm, could you test with selfrando d070755 again?
With commit d070755, this is now building fine.
-
Replying to cypherpunks:
--no-insert-timestamp?This is indeed what was missing. Adding
--no-insert-timestampflags made the build reproductible.The current version patch is in branch
bug_16472_v4: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v4&id=13859a052ed60083c43dc913141b66e45ac37afbI think the only missing part now is a new selfrando version tagged which includes commit d070755.
-
There is a patch for review in branch
bug_16472_v5: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v5&id=f338e127e856d3db876ebe46e62799f0fb63fb78Trac:
Keywords: N/A deleted, TorBrowserTeam201802R added
Status: new to needs_review -
Replying to gk:
Good stuff! I am a bit confused about why the upgrade to binutils 2.30 suddenly needs all those
nsisrelated build changes. I mean the hardening flags are not really changing just with the binutils update... So, what's up with that?The reason is that binutils 2.25 added this change:
* PE binaries now once again contain real timestamps by default. To disable the inclusion of a timestamp in a PE binary, use the --no-insert-timestamp command line option.So we need to add the
--no-insert-timestampflag to make the build reproducible, which was not necessary with binutils 2.24.Alternatively, we could patch
ld/emultempl/pe.emand change this line to make it false by default:static bfd_boolean insert_timestamp = TRUE; Isn't it better just to upgrade nsis to 3.x version which Tom uses? Hardening on Windows is harmless for all programs, except ancient crap. But if nsis has problems with ASLR, why do you add
--enable-reloc-section? As you removed SSP, why-lssp?+# the nsis build system expect all toolchain binaries to be in the same*expects-
Replying to boklm:
Replying to gk:
Good stuff! I am a bit confused about why the upgrade to binutils 2.30 suddenly needs all those
nsisrelated build changes. I mean the hardening flags are not really changing just with the binutils update... So, what's up with that?The reason is that binutils 2.25 added this change: {{{
- PE binaries now once again contain real timestamps by default. To disable the inclusion of a timestamp in a PE binary, use the --no-insert-timestamp command line option. }}}
So we need to add the
--no-insert-timestampflag to make the build reproducible, which was not necessary with binutils 2.24.I understand that part and that's not the thing that confuses me. Before the patch we had "# remove hardening wrappers" but now we have "# Some of the hardening flags are causing the build to fail, so we overwrite the helpers with only the flags required to make the build reproducible." So, why do we have suddenly the need for the hardening option
-Wl,--enable-reloc-section? Just because we need to deal with--no-insert-timestamp?Alternatively, we could patch
ld/emultempl/pe.emand change this line to make it false by default: {{{ static bfd_boolean insert_timestamp = TRUE; }}}I think we don't want that.
-
Replying to gk:
I understand that part and that's not the thing that confuses me. Before the patch we had "# remove hardening wrappers" but now we have "# Some of the hardening flags are causing the build to fail, so we overwrite the helpers with only the flags required to make the build reproducible." So, why do we have suddenly the need for the hardening option
-Wl,--enable-reloc-section? Just because we need to deal with--no-insert-timestamp?Ah, I think we only need
--no-insert-timestampand not the other options. I will make a new revision of the patch keeping only--no-insert-timestamp.Trac:
Status: needs_information to needs_revision -
Replying to boklm:
Ah, I think we only need
--no-insert-timestampand not the other options. I will make a new revision of the patch keeping only--no-insert-timestamp.I made a new revision of the patch in branch
bug_16472_v6: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v6&id=5a9277e9322117f9c8ebe53f1f447fa69293933aTrac:
Keywords: TorBrowserTeam201803 deleted, TorBrowserTeam201803R added
Status: needs_revision to needs_review -
I made test builds with your patch but both the 32bit and the 64bit bundles are crashing for me right on start. In the debugger I see tons of messages like
warning: 0f64:0944 @ 01846240 - LdrpSnapThunk - WARNING: Hint index 0x119 for pr ocedure "NtEnumerateKey" in DLL "ntdll.dll" is invalid warning: 0f64:0944 @ 01846256 - LdrpSnapThunk - WARNING: Hint index 0x3bb for pr ocedure "RtlIntegerToUnicodeString" in DLL "ntdll.dll" is invalid warning: 0f64:0944 @ 01846287 - LdrpSnapThunk - WARNING: Hint index 0x26e for pr ocedure "RtlAppendUnicodeStringToString" in DLL "ntdll.dll" is invalid warning: 0f64:0944 @ 01846303 - LdrpSnapThunk - WARNING: Hint index 0x4a7 for pr ocedure "RtlStringFromGUID" in DLL "ntdll.dll" is invalid ```. **Trac**: **Status**: needs_review **to** needs_revision **Keywords**: TorBrowserTeam201803R **deleted**, TorBrowserTeam201803 **added** Replying to gk:
I made test builds with your patch but both the 32bit and the 64bit bundles are crashing for me right on start. In the debugger I see tons of messages like {{{ warning: 0f64:0944 @ 01846240 - LdrpSnapThunk - WARNING: Hint index 0x119 for pr ocedure "NtEnumerateKey" in DLL "ntdll.dll" is invalid
warning: 0f64:0944 @ 01846256 - LdrpSnapThunk - WARNING: Hint index 0x3bb for pr ocedure "RtlIntegerToUnicodeString" in DLL "ntdll.dll" is invalid
warning: 0f64:0944 @ 01846287 - LdrpSnapThunk - WARNING: Hint index 0x26e for pr ocedure "RtlAppendUnicodeStringToString" in DLL "ntdll.dll" is invalid
warning: 0f64:0944 @ 01846303 - LdrpSnapThunk - WARNING: Hint index 0x4a7 for pr ocedure "RtlStringFromGUID" in DLL "ntdll.dll" is invalid }}}. bump mingw-w64 ;)
-
Replying to cypherpunks:
bump mingw-w64 ;)
Building firefox with
masterfrom mingw-w64 fails with:i686-w64-mingw32-widl: /var/tmp/build/mingw-w64-b633824ecafd/mingw-w64-tools/widl/src/typetree.h:274: type_alias_get_aliasee: Assertion `type_is_alias(type)' failed. Aborted Makefile:109: recipe for target 'typelib_done' failed -
Replying to boklm:
Replying to cypherpunks:
bump mingw-w64 ;)
Building firefox with
masterfrom mingw-w64 fails with: {{{ i686-w64-mingw32-widl: /var/tmp/build/mingw-w64-b633824ecafd/mingw-w64-tools/widl/src/typetree.h:274: type_alias_get_aliasee: Assertion `type_is_alias(type)' failed. Aborted Makefile:109: recipe for target 'typelib_done' failed }}}Yeah, we should not do that right now, at least not until we found the issue why the crash is happening (fwiw I notified Jacek about it, see the stylo bug on Mozilla's bug tracker as a patch from him is causing that breakage). I think picking the latest stable that works and filing an upstream bug (making sure it is still unfixed) seems like a good idea to me.
-
In branch
bug_16472_v7we are using binutils 2.29: https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_16472_v7&id=0897db8e3662ec5d606e6faf27d470915feea975The Windows i686 and x86_64 builds from this branch are working for me.
Trac:
Keywords: TorBrowserTeam201803 deleted, TorBrowserTeam201803R added
Status: needs_revision to needs_review Replying to gk:
Replying to boklm:
Replying to cypherpunks:
bump mingw-w64 ;)
Building firefox with
masterfrom mingw-w64 fails with: {{{ i686-w64-mingw32-widl: /var/tmp/build/mingw-w64-b633824ecafd/mingw-w64-tools/widl/src/typetree.h:274: type_alias_get_aliasee: Assertiontype_is_alias(type)' failed. Aborted Makefile:109: recipe for target 'typelib_done' failed }}} It can be something recent and close to binutils 2.30 release date, not necessarymaster`. Yeah, we should not do that right now, What about Nightlies? at least not until we found the issue why the crash is happening Do you mean https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9d9c67b06c1bf4c4550e3de0eb575c2bfbe96df9 ? (fwiw I notified Jacek about it, see the stylo bug on Mozilla's bug tracker as a patch from him is causing that breakage). Where? I think picking the latest stable that works 2.29.1 ? and filing an upstream bug (making sure it is still unfixed) seems like a good idea to me. Hrm...
