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

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Feb 7 15:54:01 UTC 2019


#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 cypherpunks33):

 Additional notes:
 > The build script follows mostly https://hg.mozilla.org/releases/mozilla-
 esr60/file/e93a8e6c81dc/taskcluster/scripts/misc/build-clang-trunk-
 mingw.sh.
 `    echo "Provide either x86 or x64 to specify a toolchain."`
 There is no reason to ignore all ARM toolchains.

 `  crt_flags="--enable-lib32 --disable-lib64"`
 `  crt_flags="--disable-lib32 --enable-lib64"`
 For bi-arch x86 toolchain only.

 `  WRAPPER_FLAGS="-fsjlj-exceptions"`
 Better to have no exceptions than that. In short for now: it should be
 removed. Yes, it requires activating SafeSEH throughout the toolchain by
 default.

 `make_flags="-j$(nproc)"`
 Official builds use Ninja, and we should.

 `  patch -p1 < $HOME_DIR/src/build/build-clang/math.patch`
 The problem here is that when you add LLVM as a drop-in replacement for
 GCC (and not only clang for gcc), you shouldn't forget about MinGW-w64 is
 part of the GCC toolchain and expects to see GNU C/C++. Therefore, we
 should compile clang with `-std=gnu++14` instead of `-std=c++14`, used for
 clang-cl in build-clang.py

 `git clone https://github.com/llvm-mirror`
 We should use the official svn repo as in build-clang.py or the official
 github repo as recommended in https://llvm.org/docs/GettingStarted.html
 #checkout-llvm-from-git
 What's the reason of using unofficial repo from google dog?

 `  compiler_flags="--sysroot \$DIR/../$machine-w64-mingw32 -rtlib
 =compiler-rt -stdlib=libc++ -fuse-ld=lld $WRAPPER_FLAGS -fuse-cxa-atexit
 -Qunused-arguments"`
 Briefly, `-rtlib=compiler-rt -stdlib=libc++ -fuse-ld=lld $WRAPPER_FLAGS
 -fuse-cxa-atexit` should be added to defaults in compiler driver as in
 GCC.

 `                                                 --enable-sdk=all \`
 Useless.

 `                                                 --with-default-
 msvcrt=ucrt \`
 It should be set as default in upstream, because targeting ancient MS
 VC7's `msvcrt.dll` in project that dropped support for Windows XP is a
 nonsense, and it is forbidden by MS.

 {{{
                                              CC="$CC" \
                                              AR=llvm-ar \
                                              RANLIB=llvm-ranlib \
                                              DLLTOOL=llvm-dlltool \
 }}}
 and similar. Generally, they shouldn't be needed when symlinks from
 previous comment are used.

 `      -DCMAKE_C_COMPILER_TARGET=$compiler_rt_machine-windows-gnu \`
 We want native Windows, not GNU.

 `  # Below, we specify -g -gcodeview to build static libraries with debug
 information.`
 Official build-clang.py supports these:

 `* build_type: The type of build to make.  Supported types: Release,
 Debug, RelWithDebInfo or MinSizeRel.`
 The bug here seems to be that they add `-g -gcodeview` to `Release`
 instead of `RelWithDebInfo`.
 Also adding `build_type` feature to our LLVM toolchain could help to make
 true `Release` and `Debug` builds!

 `      -DCMAKE_CXX_FLAGS="${DEBUG_FLAGS} -nostdinc++
 -I$SRC_DIR/libcxx/include -DPSAPI_VERSION=2" \`
 This requires thorough investigation.

 `      -DCMAKE_CXX_FLAGS="${DEBUG_FLAGS}
 -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_HAS_THREAD_API_WIN32"
 \`
 These should be set automatically in upstream.

 {{{
       -DLIBCXX_ENABLE_EXPERIMENTAL_LIBRARY=OFF \
       -DLIBCXX_ENABLE_FILESYSTEM=OFF \
 }}}
 Really? What else? It's better to minimize the number of explicitly set
 defines.
 To be continued...

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


More information about the tor-bugs mailing list