[tor-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 gk):

 Replying to [comment:34 cypherpunks]:
 > Replying to [comment:33 gk]:
 > > for providing mingw-w64/clang
 > The project is mature enough to be self-hosted and decided to have a
 name 'LLVM', and `clang` is used only as a name of one of its front-ends.

 Yeah, the name `mingw-w64-clang` is good for the rbm project it shows that
 more than one part is involved and it's often contrasted with
 mignw-w64/gcc. So I think we are fine here.

 > > 4) We are omitting the `DEBUG_FLAGS` (-g -gcodeview)
 > But not omitting https://hg.mozilla.org/releases/mozilla-
 esr60/rev/434bde49b9c8#l3.20

 Yeah, I think we should make that optional, too. Mostly because we can't
 build the 32bit version as linking fails due to memory issues on my
 machines at least. And it might be better suited for setting something
 like `ac_add_options --enable-debug-symbols`.

 > > 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.

 > > 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.

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