[tbb-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 tbb-bugs
mailing list