Some building experiments on different platforms

[arbipher]

I did some preliminary experiments on building checkedc-clang using more compilers on different platforms. I would like to share some results here.

Experiments are conducted on the recent latest commit on the master branch. They are not the same commits but it shouldn't matter too much.

Mac

On macOS Big Sur, using clang 12. Both ninja and ninja check run well. There are 13 failed tests in total: 10 on 3C tests, 2 on OCaml bindings, 1 on typechecking.

Failed Tests (13):
  Clang :: 3C/base_dir_trailing_slash.c
  Clang :: 3C/base_subdir/canwrite_constraints_symlink.c
  Clang :: 3C/cli_errors.c
  Clang :: 3C/generated_tests/arrstructsafemulti2.c
  Clang :: 3C/json_formatting.c
  Clang :: 3C/json_formatting_backslash.c
  Clang :: 3C/manyprotos.c
  Clang :: 3C/merge_fp2.c
  Clang :: 3C/mergebodies1.c
  Clang :: 3C/stdout_mode_write_other.c
  LLVM :: Bindings/OCaml/executionengine.ml
  LLVM :: Bindings/OCaml/target.ml
  checkedc :: checkedc/tests/typechecking/errno-use.c

The mac is a late 2019 model (Intel i9-9980hk 8 cores, 16G memory). The fresh compilation and testing take about 50 minutes each. ccache is applicable and incremental building is fast.

Ubuntu on WSL 2, Windows

I have a ubuntu 20.04 running on the Windows Subsystem for Linux (WSL 2). The compilation can never finish on the machine (AMD Ryzen 5 3600 6 cores, 32G memory). The compilation using gcc is extremely slow and it soon uses up all the memory then halts the virtual container.

Conclusion: WSL 2 is not a good choice to build clang.

Visual Studio Community 2019, Windows

The only change is to load the community version of vcvarsall.bat. It works perfectly just like the Enterprise version. The machine (AMD Ryzen 9 5950X 16 cores, 32G memory) takes 15 minutes to build and 25 minutes to test.

Python3 cmake and ninja are windows binaries. That is to say, no other gnu/unix tools are needed for the pure windows build. ccache is not applicable.

Mingw-w64 gcc, Windows

There is a group of approaches to make gnu/unix tools work on windows. The difference among them is whether one is POSIX-compatible and the C header files / dynamic libraries it uses. Or whether you would like your program to run also on linux or just run on Windows. For the project, I prefer the latter since we don't need to take its linux part on windows. ccache is applicable for them.

I use MSYS2. It contains multiple environments to play with. Environment MSYS is most like cygwin, a POSIX-compatible one, which is ignored in my experiments. The rest environments are based on Mingw-w64, not POSIX-compatible. Environment CLANG64 is most interesting to me: it uses clang and links to Universal CRT.

I test with the environment MINGW64, which uses gcc to build, and links to msvcrt(MS VC++ runtime) and libstdc++. The machine (AMD Ryzen 9 5950X 16 cores, 32G memory) takes 10 minutes to build and 20 minutes to test.

Failed Tests (629):
  Clang :: 3C/ (500+ tests)
  ...
  checkedc :: checkedc/tests/dynamic_checking (28 tests)

  LLVM :: Object/archive-extract.test
  LLVM :: Object/archive-toc.test
  LLVM :: tools/llvm-ar/empty-uid-gid.test
  LLVM :: tools/llvm-config/system-libs.windows.test
  LLVM :: tools/llvm-elfabi/fail-file-write-windows.test
  LLVM :: tools/llvm-libtool-darwin/deterministic-library.test
  LLVM :: tools/llvm-objcopy/ELF/deterministic-archive.test
  LLVM :: tools/llvm-ranlib/D-flag.test
  checkedc :: checkedc/tests/checked_headers/redeclare_libs_explicit.c
  checkedc :: checkedc/tests/checked_headers/redeclare_libs_implicit.c

I guess 3C and dynamic_checking tests are failed for no unix tools. The rest is just a few and probably also caused by lacking POSIX C headers. The result looks good to me.

For all the previous experiments, I don't touch the source but for the mingw-based environments, I did this patch.

271c271
<   int Res = _putenv_s("LLVM_THREADPOOL_AFFINITYMASK", "1");
---
>   int Res = setenv("LLVM_THREADPOOL_AFFINITYMASK", "1", false);

The bug is caused in ThreadPool.cpp. In its header, it guards the code by an inaccurate macro _MSC_VER (set by msvc) to detect the windows platform. Using __MINGW__ may be correct.

#ifdef _MSC_VER
#define setenv(name, var, ignore) _putenv_s(name, var)
#endif

Clang on Windows

I tried to use llvm/clang official windows binary to build checkedc-clang, but I haven't succeeded yet.

Experiment Conclusion

1. clang works.
2. Mac os works. Mac os has ccache.
3. Visual Studio Community 2019 works. You can have no Gnu/unix tools on windows. No ccache yet.
4. MSYS2/MINGW64 works with ccache. You can have no Visual Studio on windows.
5. WSL 2 can hardly work.

Extra

One resource for the building is the install scripts at each package management registry, e.g.

• Debian/apt https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/11/debian/rules
• MSYS2/mingw https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-clang/PKGBUILD
• mac/homebrew https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/llvm.rb
• clang-windows-binary https://gist.github.com/tru/f39b1b5df78e4084b5af53769a250c9b (I got it here)