[tbb-bugs] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:
                                                 |  needs_review
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201902R,      |  Actual Points:
  GeorgKoppen201902                              |
Parent ID:  #28238                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by cypherpunks):

 Replying to [comment:37 gk]:
 > Replying to [comment:36 cypherpunks]:
 > > Replying to [comment:35 gk]:
 > > > Replying to [comment:34 cypherpunks]:
 > > > > Replying to [comment:33 gk]:
 >
 > [snip]
 Seems you're burying in it: llvm in mingw-w64-clang, mingw-w64 in
 mingw-w64-source, LLVM in llvm, mingw-w64-gcc in mingw-w64...
 [snip]
 > > > > > lld patch for optionally dealing with PE header timestamp issues
 (by zeroing them out similar to ld's -Wl,--no-insert-timestamp). I'll try
 to get that one upstreamed.
 > > > > Could you also try to get upstreamed that:
 > > > > {{{
 > > > > -  if (Args.getLastArgValue(OPT_m) != "thumb2pe" &&
 > > > > -    Args.getLastArgValue(OPT_m) != "arm64pe" &&
 !Args.hasArg(OPT_dynamicbase))
 > > > > -      Add("-dynamicbase:no");
 > > > > }}}
 > > > > because it's a shame in 2019.
 > > >
 > > > We make that explicit by passing on `-Wl,--dynamicbase`, which seems
 sufficient to me without extra work and discussion.
 > > From which try? And how many other flags are missing/improperly
 passed? Silently, without discussion, yeah.
 >
 > What do you mean with "from which try"?
 Tries on Try.
 > See the patch that landed on esr60 and enabled that for mingw-w64/clang
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1520308).
 Yes, there is mentioning about that it's not an optional hardening.
 Unaddressed.
 > I you feel we are missing flags compared to what we currently have and
 what we should have, please file tickets here in case they are not filed
 yet.
 Filed more than a year ago. Unaddressed.
 > > > > > I played a bit with bumping the llvm revision to r351992 in
 order to get a proper `llvm-strip` and `llvm-objcopy` but run into a bunch
 of issues which made me pause for now (see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1471698 for context).
 > > > > Why not use 8.x branch as Mozilla?
 > > >
 > > > We do, but the idea was to have proper fixes for `llvm-strip` and
 `llvm-objcopy` included instead of the hacks/workarounds we and Mozilla
 have currently in place instead.
 > > No, you don't, but LLVM seems is not going to merge those fixes into
 8.x :( There is an idea to bump LLVM to rc2 (if you wish), but build
 `llvm-strip` and `llvm-objcopy` separately from trunk.
 >
 > Yes, we *do* use the same revision as Mozilla on esr60: r348363.
 It's not Mozilla official. See
 https://bugzilla.mozilla.org/show_bug.cgi?id=1512921 for the reason.
 >  We could build those things separately but I am not convinced yet that
 this is worth the effort and the extra complication and potential
 instability.
 So, building binutils now and in LLVM to create wrappers is fine for you,
 but building standalone llvm (not LLVM) to get those two utils is somewhat
 different?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28716#comment:38>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online