[9.0.0 Release] Release Candidate 1 is here

Hi everyone,

9.0.0-rc1 was just tagged from the release_90 branch at r367217
(tagged as llvmorg-9.0.0-rc1 in the Git monorepo).

Source code and docs are available at LLVM 9.0.0 Release Candidates

Binaries will be added as they become available.

Please file bug reports for any issues you find as blockers of
https://llvm.org/PR42474

Release testers: please start your engines, run the script, share your
results, and upload binaries.

Thanks,
Hans

Windows is ready:

$ sha256sum LLVM-9.0.0-rc1-win*.exe
94ecc9f92776d1934f0925bdf39ccb2ec8c36c87f05571e048d3077e7deee72c
LLVM-9.0.0-rc1-win32.exe
cc1f4b0ce47598e51c2185b21dc74ab3e053380cebf3ad92381fb083d6ec7b14
LLVM-9.0.0-rc1-win64.exe

They were built with the attached batch file.

Because of https://bugs.llvm.org/show_bug.cgi?id=42724, the binaries
don't include LLDB.

Thanks,
Hans

build_llvm_900-rc1.bat|attachment (5.65 KB)

I've reported a regression with lit test suite [1], and LLDB is still
broken on Gentoo (maybe I'll manage to get it fixed for -11? ;-)).
Other than that, it looks fine.

[1] https://bugs.llvm.org/show_bug.cgi?id=42812

From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Hans
Wennborg via llvm-dev

...

9.0.0-rc1 was just tagged from the release_90 branch at r367217 (tagged as
llvmorg-9.0.0-rc1 in the Git monorepo).

Source code and docs are available at LLVM 9.0.0 Release Candidates

rc1 clang fails to build on SLES11 (based on glibc-2.11), opened PR 42824.

/local/mnt/workspace/bcain_0721/llvm/utils/release/rc1/llvm.src/tools/clang/lib/DirectoryWatcher
/linux/DirectoryWatcher-linux.cpp:339:9: error: use of undeclared identifier 'IN_EXCL_UNLINK'

Hi,
looks good so far -- I've updated the OpenMandriva devel tree to use it as the default compiler. I've also flipped the default linker over to lld.
So far no serious problems even with lld.
Complete system rebuild isn't complete yet, but it successfully rebuilt all of Qt and KDE (on x86_64, x86_32, aarch64 and armv7hnl).
RISC-V not built yet due to HW outage.

ttyl
bero

Uploaded ARM and AArch64:
1e091722ba37c983d0b1bc97374a43bfc097833d94377ad4e8ef2353d5bec315
clang+llvm-9.0.0-rc1-aarch64-linux-gnu.tar.xz
e88a380e7498985fed572893a333408aba595b3efbf3a730cedb2ae4399a18a2
clang+llvm-9.0.0-rc1-armv7a-linux-gnueabihf.tar.xz

Both suffer from PR42739 (difference between Phase 2 and Phase 3 files).
Also opened PR42841 for AArch64 libfuzzer test failures.

Cheers,
Diana

Uploaded Ubuntu 18.04 binaries:
190157033defcfc0796f06696a73979cb4201594 clang+llvm-9.0.0-rc1-x86_64-linux-gnu-ubuntu-18.04.tar.xz

I had three phase 2/3 comparison failures, opened PR42855.

Comparing Phase 2 and Phase 3 files

file MachO_x86_64.cpp.o differs between phase 2 and phase 3
file JITLinkGeneric.cpp.o differs between phase 2 and phase 3
file llvm-config.cpp.o differs between phase 2 and phase 3

Looks good with our internal build script and all tests pass (we don't compare Stage 3 though).

One note: I wasn't able to compile with GCC 4.8.5 (CentOS 7 default), even with "-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON". This is because libcxxabi uses "__builtin_add_overflow" which was introduced with GCC 5. So I guess this is fine, given that "-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON" already prints a noticeable warning and LLVM will switch to C++14 soon which requires GCC 5.1 or later. I was able to build using GCC 6 without problems.

Regards,
Jonas

Hi Hans,

It looks like this batch file is self hosting with clang-cl but not using lld-link to link the packaged binaries, despite building it in stage0. Is that correct? If so, is there a reason why this can’t use lld-link?

Thanks
Russ

The sanitizer tests went a lot better now, thanks to Alexander Richardson's patches in https://bugs.llvm.org/show_bug.cgi?id=40761 (https://reviews.llvm.org/D65221 and https://reviews.llvm.org/D65705).

Uploaded:

SHA256 (clang+llvm-9.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 6a6c04e2d87ef3d8b8671b175afe0a59d3f5fee6d758d3c3383a6af3031b76a4
SHA256 (clang+llvm-9.0.0-rc1-i386-unknown-freebsd11.tar.xz) = d34d0d46d93576c27e6ab2a5fa4712c80fe0580dd5ca9efadd5b0b2a0b1a150f

I had to apply a number of other patches (see attachments) to make the sanitizer tests work at all, and for a few other issues:

* https://bugs.llvm.org/show_bug.cgi?id=42892 - After r356631, Sanitizer-i386-Test faills to link on FreeBSD
* https://bugs.llvm.org/show_bug.cgi?id=42893 - FreeBSD needs LD_32_LIBRARY_PATH support in lit for 32-bit dynamic ASan tests
* https://bugs.llvm.org/show_bug.cgi?id=42894 - FreeBSD needs -pthread link flag for dynamic ASan tests

Main test results on amd64-freebsd11:

fix-cfe-1.diff (451 Bytes)

fix-compiler-rt-1.diff (2.83 KB)

fix-compiler-rt-2.diff (892 Bytes)

fix-compiler-rt-3.diff (3.62 KB)

fix-compiler-rt-4.diff (900 Bytes)

fix-test-suite-1.diff (550 Bytes)

Many of the failing libc++ tests are explicitly XFAILed for NetBSD; I wonder if they should also be for FreeBSD.

– Marshall


Failing Tests (120):
libc++ :: libcxx/thread/thread.threads/thread.thread.this/sleep_for.pass.cpp

I don’t know about this one.

libc++ :: std/language.support/support.runtime/ctime.pass.cpp

Does your C library have “timespec_get” ?

libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp

These contain:

// NetBSD does not support LC_COLLATE at the moment
// XFAIL: netbsd

libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp

These contain:

// NetBSD does not support LC_MONETARY at the moment
// XFAIL: netbsd

libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
libc++ :: std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
libc++ :: std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp

These contain:

// NetBSD does not support LC_TIME at the moment
// XFAIL: netbsd

libc++ :: std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
libc++ :: std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp

These contain:

// NetBSD does not support LC_NUMERIC at the moment
// XFAIL: netbsd

libc++ :: std/re/re.alg/re.alg.match/awk.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp

libc++ :: std/re/re.traits/lookup_collatename.pass.cpp
libc++ :: std/re/re.traits/transform_primary.pass.cpp

These contain:
// NetBSD does not support LC_COLLATE at the moment
// XFAIL: netbsd

Is this also a problem for FREEBSD?

libc++ :: std/utilities/time/date.time/ctime.pass.cpp

Does your C library have “timespec_get” ?

Hi Russell,

There's no fundamental reason more than that the script is old (from
before lld had Windows support) and hasn't been updated to use lld for
the bootstrap. I gave it a quick try but ran into problems linking the
openmp library. I was probably holding it wrong, but I probably won't
try to change the script during the release process. It would be nice
to bootstrap with lld in the future, though.

Thanks,
Hans

I have here on Xubuntu 19.04

sha256sum clang+llvm-9.0.0-rc1-x86_64-pc-linux-gnu.tar.xz
13a8a150127d0a515e229598a912dc4be779ebfe0b5c44fde5231617466265f1

from instructions on under test-release.sh.

Looks like it might be uploaded in relation to but how to do that is not immediately seen.

The tail of the output gives

– Testing: 919 tests, 7 threads –
Testing: 0 … 10… 20… 30… 40… 50… 60… 70… 80… 90…
Testing Time: 438.71s
Expected Passes : 919
[100%] Built target check

Packaging the release as clang+llvm-9.0.0-rc1-x86_64-pc-linux-gnu.tar.xz

Testing Finished

Logs: /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/logs

Errors:

[Release Phase3] check-all failed
[Release+Asserts Phase3] check-all failed

No doubt there may be more information of use but where it may be, what you may want, is not clear.

Regards, Neil Nelson

Many of the failing libc++ tests are explicitly XFAILed for NetBSD; I wonder if they should also be for FreeBSD.

If they can't be fixed, then indeed they should be XFAILed. But maybe not right away, see below.

   libcxx/thread/thread.threads/thread.thread.this/sleep_for.pass.cpp
I don't know about this one.

Apparently it slept for too long:

Assertion failed: (std::abs(ns.count()) < err.count()), function main, file /home/dim/llvm/9.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/thread/thread.threads/thread.thread.this/sleep_for.pass.cpp, line 68.

Cause is unknown.

          libc++ :: std/language.support/support.runtime/ctime.pass.cpp
Does your C library have "timespec_get" ?

Yes, but it got introduced only in FreeBSD 12.0. I ran the tests on FreeBSD 11.3, where it got:

/home/dim/llvm/9.0.0/rc1/llvm.src/projects/libcxx/test/std/language.support/support.runtime/ctime.pass.cpp:25:2: error: TIME_UTC not defined

This could be worked around by checking the FreeBSD major version, using e.g. "#if __FreeBSD__ >= 12".

          libc++ ::
   std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp

For this particular test, FreeBSD, Linux and Windows seem to have a different opinion than macOS on the result of std::strcoll("aaaaaaA", "BaaaaaA"), when the locale is en_US.UTF-8:

* macOS 10.14 gives 31
* FreeBSD 13.0 gives -13
* Linux (Ubuntu 18.04) gives -1
* Windows 10 (VS 2017) gives -1

E.g. macOS, which the test appears to be based on, is the odd one out here. :slight_smile:

I won't pretend to fully understand the Unicode collation rules, but it could be that macOS does a case insensitive comparison, while the other systems do a case sensitive comparison.

          libc++ ::
   std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp

This test failed because it segfaults on FreeBSD, due to a bug in our wcsxfrm_l(3). :slight_smile:

I have fixed the bug in FreeBSD 13 here: [base] Revision 350697, but it may take a while before it is merged into FreeBSD 12 and 11.

These contain:
// NetBSD does not support LC_COLLATE at the moment
// XFAIL: netbsd
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
These contain:
// NetBSD does not support LC_MONETARY at the moment
// XFAIL: netbsd
          libc++ ::
   std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
          libc++ ::
   std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
These contain:
// NetBSD does not support LC_TIME at the moment
// XFAIL: netbsd
          libc++ ::
   std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
          libc++ ::
   std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
These contain:
// NetBSD does not support LC_NUMERIC at the moment
// XFAIL: netbsd
          libc++ :: std/re/re.alg/re.alg.match/awk.pass.cpp
          libc++ :: std/re/re.alg/re.alg.match/basic.pass.cpp
          libc++ :: std/re/re.alg/re.alg.match/ecma.pass.cpp
          libc++ :: std/re/re.alg/re.alg.match/extended.pass.cpp
          libc++ :: std/re/re.alg/re.alg.search/awk.pass.cpp
          libc++ :: std/re/re.alg/re.alg.search/basic.pass.cpp
          libc++ :: std/re/re.alg/re.alg.search/ecma.pass.cpp
          libc++ :: std/re/re.alg/re.alg.search/extended.pass.cpp
          libc++ :: std/re/re.traits/lookup_collatename.pass.cpp
          libc++ :: std/re/re.traits/transform_primary.pass.cpp
These contain:
// NetBSD does not support LC_COLLATE at the moment
// XFAIL: netbsd
Is this also a problem for FREEBSD?

FreeBSD does support all the LC_xxx functionality, but it could very well be that the output of the above tests is slightly different from what is expected. I will have to look into all the individual cases to see what is going wrong.

          libc++ :: std/utilities/time/date.time/ctime.pass.cpp
Does your C library have "timespec_get" ?

See above, from FreeBSD 12 onwards.

-Dimitry

Hi Neil,

I have here on Xubuntu 19.04

sha256sum clang+llvm-9.0.0-rc1-x86_64-pc-linux-gnu.tar.xz
13a8a150127d0a515e229598a912dc4be779ebfe0b5c44fde5231617466265f1

from instructions on https://llvm.org/docs/ReleaseProcess.html under test-release.sh.

Looks like it might be uploaded in relation to LLVM 9.0.0 Release Candidates but how to do that is not immediately seen.

Anton: can you help Neil get access to the release testers sftp?

The tail of the output gives

-- Testing: 919 tests, 7 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 438.71s
  Expected Passes : 919
[100%] Built target check
# Packaging the release as clang+llvm-9.0.0-rc1-x86_64-pc-linux-gnu.tar.xz
### Testing Finished ###
### Logs: /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/logs
### Errors:
[Release Phase3] check-all failed
[Release+Asserts Phase3] check-all failed

No doubt there may be more information of use but where it may be, what you may want, is not clear.

It would be interesting to see what the test failures are. Can you
look in the Logs directory mentioned above and see which tests failed?

Thanks,
Hans

Hans, Below is a list of all lines in the logs having the string ‘fail’.

These two lines that get repeated I was thinking early on were not that relevant but there may be some packages that would correct these.

llvm.configure-Phase3-Release+Asserts.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase3-Release+Asserts.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile

This next line seems more serious.

testing.9.0.0-rc1.log:LLVMExegesisTests: /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/llvm.src/tools/llvm-exegesis/lib/PerfHelper.cpp:104: llvm::exegesis::pfm::Counter::Counter(const llvm::exegesis::pfm::PerfEvent &): Assertion `FileDescriptor != -1 && “Unable to open event”’ failed.

A day ago I compiled the current master release, 8.0.1, in debug using the flag -DLLVM_ENABLE_LIBPFM=OFF that corrected an error that may be related. Although how that would carry over to the test-release process is not known.

Regards, Neil Nelson

~/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/logs
grep fail *deferred_errors.log:[Release Phase3] check-all failed
deferred_errors.log:[Release+Asserts Phase3] check-all failed
llvm.configure-Phase1-Release+Asserts.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase1-Release+Asserts.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
llvm.configure-Phase1-Release.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase1-Release.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
llvm.configure-Phase2-Release+Asserts.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase2-Release+Asserts.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
llvm.configure-Phase2-Release.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase2-Release.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
llvm.configure-Phase3-Release+Asserts.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase3-Release+Asserts.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
llvm.configure-Phase3-Release.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
llvm.configure-Phase3-Release.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:: ‘RUN: at line 21’; not /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/Phase3/Release/llvmCore-9.0.0-rc1.obj/projects/compiler-rt/test/fuzzer/X86_64StaticLibcxxLinuxConfig/Output/fork.test.tmp-ShallowOOMDeepCrash -fork=1 -rss_limit_mb=128 -ignore_crashes=1 -max_total_time=10 2>&1 | FileCheck /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/llvm.src/projects/compiler-rt/test/fuzzer/fork.test --dump-input-on-failure --check-prefix=MAX_TOTAL_TIME
testing.9.0.0-rc1.log:[Release Phase3] check-all failed
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile
testing.9.0.0-rc1.log:LLVMExegesisTests: /home/nnelson/Documents/llvm-project-llvmorg-8.0.1-rc4/llvm/utils/release/rc1/llvm.src/tools/llvm-exegesis/lib/PerfHelper.cpp:104: llvm::exegesis::pfm::Counter::Counter(const llvm::exegesis::pfm::PerfEvent &): Assertion `FileDescriptor != -1 && “Unable to open event”’ failed.
testing.9.0.0-rc1.log:[Release+Asserts Phase3] check-all failed
testing.9.0.0-rc1.log:-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES – failed to compile
testing.9.0.0-rc1.log:-- Performing Test HAVE_GNU_POSIX_REGEX – failed to compile