Opened 11 months ago

Closed 4 weeks ago

#28238 closed defect (fixed)

Use mingw-w64/clang toolchain to build Firefox

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, tbb-9.0-must-nightly, TorBrowserTeam201908R, GeorgKoppen201908
Cc: tom, boklm Actual Points:
Parent ID: #30322 Points:
Reviewer: Sponsor:

Description

We want to use the clang-based mingw-w64 toolchain to build Firefox to be finally able to enabled Stylo on Windows as well. This is the ticket tracking the implementation work

Child Tickets

TicketStatusOwnerSummaryComponent
#28716closedtbb-teamCreate a mingw-w64-clang projectApplications/Tor Browser
#29307closedtbb-teamUse Debian Stretch for cross-compiling our Windows buildsApplications/Tor Browser

Attachments (1)

fxexe_diff.bz2 (1.7 MB) - added by gk 8 months ago.
diff firefox.exe

Download all attachments as: .zip

Change History (55)

comment:1 Changed 11 months ago by gk

We likely start small and just use the toolchain to build the Firefox part which means we'd have two mingw-w64 toolchains for the time being (we had this back then in the old days for macOS, too). I guess other parts of the whole bundle might need quite some amount of work to getting built with that new toolchain and we want to move fast here aiming for Tor Browser 8.5.

However, if it turns out I am wrong and it is indeed easy to use mingw-w64/clang for everything, fine with me.

comment:2 Changed 10 months ago by gk

Keywords: TorBrowserTeam201812 GeorgKoppen201812 added

comment:3 Changed 9 months ago by gk

Keywords: GeorgKoppen201901 added; GeorgKoppen201812 removed

Moving my tickets.

comment:4 Changed 9 months ago by gk

Testing bug_28238 shows that we have some reproducibility issues with mingw-w64/clang. It seems we have to deal at least with timestamp issues in the COFF header. Comparing e.g. firefox.exe from two different runs shows:

--- /dev/fd/63	2019-01-10 09:38:08.159230047 +0100
+++ /dev/fd/62	2019-01-10 09:38:08.159230047 +0100
@@ -6,7 +6,7 @@
 00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
 00000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS 
 00000070: 6d6f 6465 2e24 0000 5045 0000 4c01 0600  mode.$..PE..L...
-00000080: 3b1c 365c 003c 0000 a201 0000 e000 2201  ;.6\.<........".
+00000080: 45ff 365c 003c 0000 a201 0000 e000 2201  E.6\.<........".
 00000090: 0b01 0e00 001e 0000 001a 0000 0000 0000  ................
 000000a0: c013 0000 0010 0000 0000 0000 0000 4000  ..............@.
 000000b0: 0010 0000 0002 0000 0600 0000 0000 0000  ................

comment:5 Changed 9 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:6 in reply to:  4 ; Changed 9 months ago by gk

Replying to gk:

Testing bug_28238 shows that we have some reproducibility issues with mingw-w64/clang. It seems we have to deal at least with timestamp issues in the COFF header. Comparing e.g. firefox.exe from two different runs shows:

--- /dev/fd/63	2019-01-10 09:38:08.159230047 +0100
+++ /dev/fd/62	2019-01-10 09:38:08.159230047 +0100
@@ -6,7 +6,7 @@
 00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
 00000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS 
 00000070: 6d6f 6465 2e24 0000 5045 0000 4c01 0600  mode.$..PE..L...
-00000080: 3b1c 365c 003c 0000 a201 0000 e000 2201  ;.6\.<........".
+00000080: 45ff 365c 003c 0000 a201 0000 e000 2201  E.6\.<........".
 00000090: 0b01 0e00 001e 0000 001a 0000 0000 0000  ................
 000000a0: c013 0000 0010 0000 0000 0000 0000 4000  ..............@.
 000000b0: 0010 0000 0002 0000 0600 0000 0000 0000  ................

FWIW: That's still an unsolved issue after bumping the LLVM revision to r348363.

comment:8 in reply to:  7 Changed 8 months ago by gk

Replying to ld:

https://bugs.chromium.org/p/chromium/issues/detail?id=533657
https://bugs.llvm.org/show_bug.cgi?id=24740#c3

That's about building _clang_ deterministic, yes. Thus, this is more suited for #29041.

comment:10 Changed 8 months ago by gk

https://reviews.llvm.org/rL332613 seems like the relevant revision for the timestamp issue.

comment:11 Changed 8 months ago by ld

  if (Args.hasArg(OPT_no_insert_timestamp))
    Add("-timestamp:0");

comment:12 Changed 8 months ago by gk

So, I have been fighting today with building the whole Firefox related part (including fxc2) without the old mingw-w64/gcc-based toolchain. fxc2 does not want and I don't know why yet. It fails to run with things like

 0:03.01 err:module:import_dll Library api-ms-win-crt-convert-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-heap-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-private-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-runtime-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-stdio-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-string-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-environment-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-math-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-time-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.03 err:module:import_dll Library api-ms-win-crt-locale-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.03 err:module:LdrInitializeThunk Main exe initialization for L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe" failed, status c0000135

I need to look closer at the way this is built on Mozilla infra tomorrow where this seems to be working.

comment:13 in reply to:  12 Changed 8 months ago by fxc2

Replying to gk:

So, I have been fighting today with building the whole Firefox related part (including fxc2) without the old mingw-w64/gcc-based toolchain.

No, no, don't fight with it! The new tool chain is much more sane. And it will make you happy.

fxc2 does not want and I don't know why yet. It fails to run with things like

 0:03.01 err:module:import_dll Library api-ms-win-crt-convert-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-heap-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-private-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-runtime-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.01 err:module:import_dll Library api-ms-win-crt-stdio-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-string-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-environment-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-math-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.02 err:module:import_dll Library api-ms-win-crt-time-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.03 err:module:import_dll Library api-ms-win-crt-locale-l1-1-0.dll (which is needed by L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe") not found
 0:03.03 err:module:LdrInitializeThunk Main exe initialization for L"Z:\\var\\tmp\\dist\\fxc2\\bin\\fxc2.exe" failed, status c0000135

Do you have wine with ucrt? FWIW, wine 4.0 is out.

I need to look closer at the way this is built on Mozilla infra tomorrow where this seems to be working.

They use https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/scripts/misc/build-wine.sh

comment:14 Changed 8 months ago by gk

Okay, I am close with this ticket. Here is a test bundle which compiles fxc2 and firefox with mingw-w64/clang while mingw-w64/gcc is used for the remaining components. I'd be interested in whether that explodes on anyone's machine:

https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_28238_1_en-US.exe
https://people.torproject.org/~gk/testbuilds/torbrowser-install-win64-tbb-nightly_28238_1_en-US.exe.asc

comment:16 Changed 8 months ago by cypherpunks

Parent ID: #29318

Whoa! Cypherpunks operational!

Of course, that explodes, but whether I'm the only one who is interested in it?

comment:17 Changed 8 months ago by cypherpunks

Parent ID: #29318

oops

comment:18 in reply to:  16 ; Changed 8 months ago by gk

Replying to cypherpunks:

Whoa! Cypherpunks operational!

Of course, that explodes, but whether I'm the only one who is interested in it?

Care to give more context? Which of the bundles did you test? On which Windows version? What happened? What error did you get, if any?

comment:19 Changed 8 months ago by gk

Keywords: GeorgKoppen201902 added; GeorgKoppen201901 removed

Moving my tickets to Feb

comment:20 in reply to:  6 Changed 8 months ago by gk

Replying to gk:

Replying to gk:

Testing bug_28238 shows that we have some reproducibility issues with mingw-w64/clang. It seems we have to deal at least with timestamp issues in the COFF header. Comparing e.g. firefox.exe from two different runs shows:

--- /dev/fd/63	2019-01-10 09:38:08.159230047 +0100
+++ /dev/fd/62	2019-01-10 09:38:08.159230047 +0100
@@ -6,7 +6,7 @@
 00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
 00000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS 
 00000070: 6d6f 6465 2e24 0000 5045 0000 4c01 0600  mode.$..PE..L...
-00000080: 3b1c 365c 003c 0000 a201 0000 e000 2201  ;.6\.<........".
+00000080: 45ff 365c 003c 0000 a201 0000 e000 2201  E.6\.<........".
 00000090: 0b01 0e00 001e 0000 001a 0000 0000 0000  ................
 000000a0: c013 0000 0010 0000 0000 0000 0000 4000  ..............@.
 000000b0: 0010 0000 0002 0000 0600 0000 0000 0000  ................

FWIW: That's still an unsolved issue after bumping the LLVM revision to r348363.

That is solved and in the process of being upstreamed. I now get identical builds on one machine. However, compared to the other one I tested they significantly differ. Not all .dlls/.exe files are affected, though, just firefox.exe, libGLESv2.dll, mozglue.dll, pingsender.exe, plugin-container.exe, plugin-hang-ui.exe, and xul.dll.

Changed 8 months ago by gk

Attachment: fxexe_diff.bz2 added

diff firefox.exe

comment:21 in reply to:  18 Changed 8 months ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

Whoa! Cypherpunks operational!

Of course, that explodes, but whether I'm the only one who is interested in it?

Care to give more context? Which of the bundles did you test? On which Windows version? What happened? What error did you get, if any?

No answers to my questions - no answers to your questions. But don't worry, it's a blocker.
There are over 1M daily users on Windows and no one here. How so? Are they fakes? Or don't care? And you, do you care about security on Windows as a primary target, or Windows is incompatible with security for you?
(5 vs 5 questions)

comment:22 Changed 8 months ago by tom

x64 build: On first run; tor failed; noting:

2/5/19, 16:46:34.346 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
2/5/19, 16:46:34.952 [WARN] ISO time "2019-02-05 16:00:00\r" was unparseable
2/5/19, 16:46:34.952 [WARN] Unable to parse networkstatus consensus

On second run (I ran firefox.exe directly but I don't think that mattered) it worked and I was able to load a website, youtube, play a video, and hit an onion site.

x86 build: same problem with the authoritity certificates. On second run (this time I used the Start Tor Browser shortcut) it worked; again with a website, onion, and youtube. (I actually exited using IPv6 too!) I confirmed ASLR on the x86 build.

All on Windows 10.

comment:23 in reply to:  22 Changed 8 months ago by boklm

Replying to tom:

x64 build: On first run; tor failed; noting:

2/5/19, 16:46:34.346 [NOTICE] Bootstrapped 40% (loading_keys): Loading authority key certs
2/5/19, 16:46:34.952 [WARN] ISO time "2019-02-05 16:00:00\r" was unparseable
2/5/19, 16:46:34.952 [WARN] Unable to parse networkstatus consensus

On second run (I ran firefox.exe directly but I don't think that mattered) it worked and I was able to load a website, youtube, play a video, and hit an onion site.

x86 build: same problem with the authoritity certificates. On second run (this time I used the Start Tor Browser shortcut) it worked; again with a website, onion, and youtube. (I actually exited using IPv6 too!) I confirmed ASLR on the x86 build.

All on Windows 10.

This looks like #28614.

comment:24 Changed 8 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

comment:25 Changed 7 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201902 removed

Moving my tickets to March.

comment:26 Changed 7 months ago by gk

Keywords: GeorgKoppen201903 added; GeorgKoppen201902 removed

Now for my keyword.

comment:27 Changed 6 months ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:28 Changed 6 months ago by gk

Keywords: GeorgKoppen201904 added; GeorgKoppen201903 removed

Moving my tickets for April

comment:29 Changed 5 months ago by gk

Parent ID: #29318#30321

comment:30 Changed 5 months ago by gk

Parent ID: #30321#30322

comment:31 Changed 5 months ago by gk

Keywords: TorBrowserTeam201905 added; TorBrowserTeam201904 removed

Moving tickets to May

comment:32 Changed 5 months ago by gk

Keywords: GeorgKoppen201905 added; GeorgKoppen201904 removed

Move my tickets.

comment:33 Changed 4 months ago by gk

Keywords: TorBrowserTeam201906 added; TorBrowserTeam201905 removed

Moving tickets to June

comment:34 Changed 4 months ago by gk

Keywords: GeorgKoppen201906 added; GeorgKoppen201905 removed

Moving my tickets to June

comment:35 Changed 3 months ago by gk

Keywords: GeorgKoppen201907 added; GeorgKoppen201906 removed

Moving my tickets to July.

comment:36 Changed 3 months ago by gk

Keywords: TorBrowserTeam201907 added; TorBrowserTeam201906 removed

Moving tickets to July

comment:37 Changed 2 months ago by gk

Keywords: tbb-9.0-must-nightly added

Starting with 9.0 keywords

comment:38 Changed 7 weeks ago by gk

Keywords: TorBrowserTeam201908 added; TorBrowserTeam201907 removed

Moving tickets to August, part 1

comment:39 Changed 5 weeks ago by gk

Keywords: GeorgKoppen201908 added; GeorgKoppen201907 removed

Move my tickets.

comment:40 Changed 4 weeks ago by gk

Keywords: TorBrowserTeam201908R added; TorBrowserTeam201908 removed
Status: newneeds_review

bug_28238_v14 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_28238_v14) has the patches to get this going. pospeselr checked that a 64bit build is working, which is nice!

The patches are on top for those for #28716 to make testing easier. One caveat are the 32bit builds wich are currently failing due to memory issues when building gkrust. I need to find some configure flags that help here or we need to bite the bullet of using a 64bit host for 32bit builds as well.

comment:41 Changed 4 weeks ago by boklm

Switching to 64bit host for the 32bit builds sounds like a good idea.

comment:42 in reply to:  41 Changed 4 weeks ago by gk

Replying to boklm:

Switching to 64bit host for the 32bit builds sounds like a good idea.

I agree with that and we should probably do that in our alpha cycle for Tor Browser 9. However, I fear that's more work involved than we have capacity in, say, the next two, three days given all the other stuff on our plate.

It seems I managed to solve the build problems for now with bug_28238_v15 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_28238_v15). Please use that one for review.

comment:43 Changed 4 weeks ago by gk

bug_28238_v16 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/log/?h=bug_28238_v16) picks up the new change from bug_28716_v14 (but does not contain new Firefox related ones.

comment:44 Changed 4 weeks ago by tom

comment:45 in reply to:  44 ; Changed 4 weeks ago by gk

Replying to tom:

I think it worked for me back then a couple of months ago when I worked on the toolchain. I'll double-check with nightly builds once things landed but am optimistic.

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

Yes, I am not sure why we don't need those but the build is not breaking, so we could leave that investigation for later.

  • I'm not sure what you do about PDBs; but it would be good to get a bug on file about generating/outputting them. (Perhaps in some configuration generating the static clang libraries with debug info also.)

I agree. Right now don't generate them.

comment:46 in reply to:  45 ; Changed 4 weeks ago by tom

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

No, from my recollection it will compile fine but won't run if the dll is missing from the directory. (However if firefox builds, then fxc2 didn't error and it worked...)

  • I'm not sure what you do about PDBs; but it would be good to get a bug on file about generating/outputting them. (Perhaps in some configuration generating the static clang libraries with debug info also.)

I agree. Right now don't generate them.

I suspect you do generate them; but without setting MOZ_COPY_PDBs they are not winding up next to the outputed files so they're not winding up in the final tarball. You could stick that into the mozconfig and see if they show up though.

comment:47 in reply to:  46 ; Changed 4 weeks ago by gk

Replying to tom:

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

No, from my recollection it will compile fine but won't run if the dll is missing from the directory. (However if firefox builds, then fxc2 didn't error and it worked...)

Another thought here: how are you compiling fxc2? I recall that I needed to resort to the .dll when compiling fxc2 with mingw-w64-gcc, which was my main motivation to use mingw-w64-clang when building fxc2 as well.

comment:48 in reply to:  47 Changed 4 weeks ago by tom

Replying to gk:

Replying to tom:

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

No, from my recollection it will compile fine but won't run if the dll is missing from the directory. (However if firefox builds, then fxc2 didn't error and it worked...)

Another thought here: how are you compiling fxc2? I recall that I needed to resort to the .dll when compiling fxc2 with mingw-w64-gcc, which was my main motivation to use mingw-w64-clang when building fxc2 as well.

No, you're right - I completely misremembered; I'm sorry. When I cut fxc2 over to mingw-clang I got rid of needing winpthread (which makes sense now that I think more deeply about it.) https://hg.mozilla.org/mozilla-central/rev/918d2aeb31eb7d18603be0c5f6ae9b27c12b6fc2

Sorry!

comment:49 in reply to:  45 Changed 4 weeks ago by gk

Replying to gk:

Replying to tom:

I think it worked for me back then a couple of months ago when I worked on the toolchain. I'll double-check with nightly builds once things landed but am optimistic.


I think this works now without the spec hack due to switching to ucrt which should be available on all supported platforms. It seems both 64bit and 32bit bundles are working both on Windows 7 and Windows 10 systems and I tried the new 32bit version on my Windows 7 box where I previously had the problem at hand. However, it works there as well now. Thus, I'd say we are good here. I'll close the respective bugs on our side once the patch for this bug lands.

Last edited 4 weeks ago by gk (previous) (diff)

comment:50 in reply to:  45 Changed 4 weeks ago by gk

Replying to gk:

Replying to tom:

I think it worked for me back then a couple of months ago when I worked on the toolchain. I'll double-check with nightly builds once things landed but am optimistic.

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

Yes, I am not sure why we don't need those but the build is not breaking, so we could leave that investigation for later.

From reading a bit more in the respective Mozilla bug I think we don't need those lines as we only have one clang available in our build environment (the one we intend to get used). Thus, there won't be any potential compiler confusion that needs to get addressed.

Last edited 4 weeks ago by gk (previous) (diff)

comment:51 in reply to:  46 Changed 4 weeks ago by gk

Replying to tom:

  • fxc2 requires the winpthread dll to be in its bin directly IIRC; but I don't see where you're copying that. (I might have missed it. If you're not getting errors on fxc2 it must be working.)

I think we don't need it when building with mingw-w64-clang. At least the build passes and I'd suspect compile time issues if that were a problem.

No, from my recollection it will compile fine but won't run if the dll is missing from the directory. (However if firefox builds, then fxc2 didn't error and it worked...)

  • I'm not sure what you do about PDBs; but it would be good to get a bug on file about generating/outputting them. (Perhaps in some configuration generating the static clang libraries with debug info also.)

I agree. Right now don't generate them.

I suspect you do generate them; but without setting MOZ_COPY_PDBs they are not winding up next to the outputed files so they're not winding up in the final tarball. You could stick that into the mozconfig and see if they show up though.

I think that might be true for 64bit, yes. However, for 32bit we explicitly set --disable-debug-symbols as we are still not cross-compiling 64bit->32bit (which #30384 should solve) and hitting out of memory errors otherwise. Anyway, I've filed #31546 for generatin/exposing PDB files.

Last edited 4 weeks ago by gk (previous) (diff)

comment:52 Changed 4 weeks ago by boklm

The patches from branch gk/bug_28238_v16 look good to me.

I think a possible improvement is defining var/setup in projects/mingw-w64-clang/config so that we can define var/compiler in the projects where we want to use it:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=1510201478c07569466e1fea83873dd1ffb4c1ca
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=d93e89635eae1718b0c44be0d698e998754d4289
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=5ef691810ea0e4f97d9262283947298756b88507

In branch bug_28238_v3 I squashed the suggested fixup patches, and rebased on master:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/log/?h=bug_28238_v3

I am currently testing a build with this branch.

comment:53 in reply to:  52 Changed 4 weeks ago by gk

Replying to boklm:

The patches from branch gk/bug_28238_v16 look good to me.

I think a possible improvement is defining var/setup in projects/mingw-w64-clang/config so that we can define var/compiler in the projects where we want to use it:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=1510201478c07569466e1fea83873dd1ffb4c1ca
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=d93e89635eae1718b0c44be0d698e998754d4289
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/commit/?h=bug_28238_v2&id=5ef691810ea0e4f97d9262283947298756b88507

In branch bug_28238_v3 I squashed the suggested fixup patches, and rebased on master:
https://gitweb.torproject.org/user/boklm/tor-browser-build.git/log/?h=bug_28238_v3

I am currently testing a build with this branch.

Works for me and the fixups look good.

comment:54 Changed 4 weeks ago by boklm

Resolution: fixed
Status: needs_reviewclosed

Ok, I merged it to master as commits 8aeb04965f9993b7572c7fe98d9ad3e0b2fe4453, 6ca067d2d716283c47c6b2fb822305e61b16e168, 9b4b31f5bacfffb2b35e914fe5535999c7db45e1, 84d95d6d2a51d93f62e9927cfa2e63e674066c7d and 023ce30eb3c6082af3353fe6876c202d849cfea8.

Note: See TracTickets for help on using tickets.