Tests do not compile with pre-release glibc

[musicinmybrain]

What is the issue you have?

In the next version of glibc, 2.34, SIGSTKSZ will be changed from a preprocessor constant to an expression involving a runtime function call. This has broken a lot of software that used it as a stack or static buffer size.

Please describe the steps to reproduce the issue.

1. Find a platform with recent enough glibc, such as Fedora 35 (Rawhide)
2. Build with CMake (or, any other approach that builds the tests).

Can you provide a small but working code example?

Not applicable.

What is the expected behavior?

Tests compile (and hopefully pass).

And what is the actual behavior instead?

[  0%] Building CXX object test/CMakeFiles/doctest_main.dir/src/unit.cpp.o
cd /builddir/build/BUILD/json-3.9.1/x86_64-redhat-linux-gnu/test && /usr/bin/g++  -I/builddir/build/BUILD/json-3.9.1/test/thirdparty/doctest -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -o CMakeFiles/doctest_main.dir/src/unit.cpp.o -c /builddir/build/BUILD/json-3.9.1/test/src/unit.cpp
In file included from /builddir/build/BUILD/json-3.9.1/test/thirdparty/doctest/doctest_compatibility.h:6,
                 from /builddir/build/BUILD/json-3.9.1/test/src/unit.cpp:31:
/builddir/build/BUILD/json-3.9.1/test/thirdparty/doctest/doctest.h:4021:47: error: size of array 'altStackMem' is not an integral constant-expression
 4021 |         static char             altStackMem[4 * SIGSTKSZ];
      |                                               ^

Which compiler and operating system are you using?

• Compiler: GCC 11
• Operating system: Fedora 35 (Rawhide)
• Libc: glibc 2.33.9000 (2.34 beta)

Which version of the library did you use?

• latest release version 3.9.1
• other release - please state the version: ___
• the develop branch

If you experience a compilation error: can you compile and run the unit tests?

• yes
• no - please copy/paste the error message below

See “actual behavior” above.

Additional information

This was reported upstream in doctest (doctest/doctest#473), fixed (doctest/doctest@099d541). Version 2.4.6, released three days ago, is the first to contain the fix.

This bug can be fixed by updating test/thirdparty/doctest/ to contain version 2.4.6.

[nlohmann]

Thanks for the PR! I was about to open one, but you were just too quick ;)

[xvitaly]

@nlohmann Maybe it will be better to implement building tests with packaged doctest versions and use bundled only if not found?

[nlohmann]

Maybe it will be better to implement building tests with packaged doctest versions and use bundled only if not found?

What do you mean with "packaged"?

[xvitaly]

What do you mean with "packaged"?

From distribution repositories. I can help with this.

[nlohmann]

You mean something like FetchContent?

[xvitaly]

You mean something like FetchContent?

No. Something like this:

find_package(FOO 1.0.0 QUIET)

IF (NOT FOO_FOUND)
    message(STATUS "Using bundled version of FOO library.")
    add_subdirectory("${CMAKE_SOURCE_DIR}/3rdparty/foo" EXCLUDE_FROM_ALL)
ENDIF()

[nlohmann]

I see. No, I don't think this is a good idea for this library. I only use the single header for doctest, and so far, updating was never an issue.

[xvitaly]

I see. No, I don't think this is a good idea for this library. I only use the single header for doctest, and so far, updating was never an issue.

We can use your old single-header logic under the IF statement.

[nlohmann]

Yes, but what is the overall benefit?

[xvitaly]

Yes, but what is the overall benefit?

I want to use only packaged version of doctest in Fedora package. I'm Fedora maintainer.

[nlohmann]

But this is only for the unit tests of this library, right?

[xvitaly]

But this is only for the unit tests of this library, right?

Yes, but if we use it during the build, we must provide virtual dependencies. That's why the packaged version is preferred.