How can I disable the compiler sanity checks?

[ilg-ul]

I'm trying to build some unit tests with a clang toolchain installed in a non-system location, and meson refuses to setup my project:

> meson setup --backend ninja --buildtype debug -D platform-name=native --native-file xpacks/micro-os-plus-build-helper/meson/toolchains/clang-linux.ini --native-file tests/platform-native/meson/native.ini build/native-meson-clang15-debug tests
The Meson build system
Version: 0.63.3
Source dir: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/tests
Build dir: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug
Build type: native build
Project name: micro-os-plus-utils-lists
Project version: undefined
C compiler for the host machine: clang (clang 15.0.7 "xPack x86_64 clang version 15.0.7")
C linker for the host machine: clang ld.bfd 2.30
/home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug/meson-private/sanitycheckcpp.exe: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory

tests/meson.build:16:0: ERROR: Executables created by cpp compiler clang++ are not runnable.

A full log can be found at /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug/meson-logs/meson-log.txt
error: running 'meson setup --backend ninja --buildtype debug -D platform-name=native --native-file xpacks/micro-os-plus-build-helper/meson/toolchains/clang-linux.ini --native-file tests/platform-native/meson/native.ini build/native-meson-clang15-debug tests' failed

I tried to add skip_sanity_check = true to the toolchain file, but it was not accepted:

ERROR: Invalid type True for entry 'skip_sanity_check' in cross file

The compiler is fully functional, and the compiled binaries are also fully functional, as long as -rpath is passed to the linker or LD_LIBRARY_PATH is set properly before executing the binaries (exactly the same tests build and run properly with CMake and the same clang).

However, with meson, I can't even build the binaries, since meson quits prematurely.

Any suggestions?

[eli-schwartz]

This sounds like https://gcc.gnu.org/faq.html#rpath

[eli-schwartz]

The compiler is not baseline usable without the rpath, correct? It generates broken binaries. You cannot assume LD_LIBRARY_PATH is set (if it is set then the sanity check binary would work too).

But it's possible to define custom spec files for gcc, so that it always does the right thing. You can even modify the builtins.

[eli-schwartz]

Simply disabling the sanity checks isn't a good solution in general. It breaks a number of cc.*() methods that need to run a binary, and check the result. There are some hacks for cross compilation that basically involve iteratively searching over maxint.

[ilg-ul]

The compiler is not baseline usable without the rpath, correct? It generates broken binaries.

The compiler is very usable. It is perfectly legal to delay setting the LD_LIBRARY_PATH right when the binary is executed, or to pass -rpath to the linker.

This is a common situation for all compilers installed in non-system locations, you have to pass a rpath pointing to the actual location when running the generated binaries, otherwise the loader either loads the wrong libraries from the system locations, or fails if the system compiler is not installed.

to define custom spec files for gcc

This discussion is about clang.

[ilg-ul]

It breaks a number of cc.*() methods that need to run a binary, and check the result.

Then there must be a way to make these checks non-mandatory.

[eli-schwartz]

Right, fair enough, for clang that would be https://clang.llvm.org/docs/UsersManual.html#configuration-files

Then there must be a way to make these checks non-mandatory.

cc.*() methods are used by meson.build files of individual projects. It highlights the generally issueful nature of the problem space.

The compiler is very usable. It is perfectly legal to delay setting the LD_LIBRARY_PATH right when the binary is executed, or to pass -rpath to the linker.

This is a common situation for all compilers installed in non-system locations, you have to pass a rpath pointing to the actual location when running the generated binaries, otherwise the loader either loads the wrong libraries from the system locations, or fails if the system compiler is not installed.

This is terrible user UX for a compiler toolchain to demonstrate, to require passing manual rpath options. It is the job of the toolchain distributor to make this simply work by default.

LD_LIBRARY_PATH is simply not a reasonable way to do anything unless it is set automatically by wrapper scripts before entering an environment within which the compiler is intended to be used and be valid.

IMHO this isn't a common situation at all. The common situation is that the toolchain vendor provides GCC specs or clang configuration files that make this work out of the box.

[eli-schwartz]

The compiler is fully functional, and the compiled binaries are also fully functional, as long as -rpath is passed to the linker or LD_LIBRARY_PATH is set properly before executing the binaries (exactly the same tests build and run properly with CMake and the same clang).

If GCC spec files / clang config files are not to your taste, then simply pass the correct rpath in your LDFLAGS to be passed to the linker.

[ilg-ul]

I'm curious, how does cmake handle your toolchain...

like this:

> cmake -S tests -B build/native-cmake-clang-debug -G Ninja -D CMAKE_BUILD_TYPE=Debug -D PLATFORM_NAME=native -D CMAKE_EXPORT_COMPILE_COMMANDS=ON --log-level=VERBOSE -D CMAKE_TOOLCHAIN_FILE=../xpacks/micro-os-plus-build-helper/cmake/toolchains/clang.cmake
-- The C compiler identification is Clang 15.0.7
-- The CXX compiler identification is Clang 15.0.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang-debug/xpacks/.bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang-debug/xpacks/.bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang-debug/xpacks/.bin/clang
...

while meson does this:

> meson setup --backend ninja --buildtype debug -D platform-name=native --native-file xpacks/micro-os-plus-build-helper/meson/toolchains/clang-linux.ini --native-file tests/platform-native/meson/native.ini build/native-meson-clang15-debug tests
The Meson build system
Version: 0.63.3
Source dir: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/tests
Build dir: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug
Build type: native build
Project name: micro-os-plus-utils-lists
Project version: undefined
C compiler for the host machine: clang (clang 15.0.7 "xPack x86_64 clang version 15.0.7")
C linker for the host machine: clang ld.bfd 2.30
/home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug/meson-private/sanitycheckcpp.exe: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory

tests/meson.build:16:0: ERROR: Executables created by cpp compiler clang++ are not runnable.

A full log can be found at /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-meson-clang15-debug/meson-logs/meson-log.txt

[ilg-ul]

And a successful run with the automatically set LD_LIBRARY_PATH looks like this:

> cd build/native-cmake-clang15-debug && ctest -V
UpdateCTestConfiguration  from :/home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang15-debug/DartConfiguration.tcl
UpdateCTestConfiguration  from :/home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang15-debug/DartConfiguration.tcl
Test project /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang15-debug
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: sample-test

1: Test command: /home/ilg/Work/micro-os-plus/utils-lists-xpack.git/build/native-cmake-clang15-debug/platform-bin/sample-test "one" "two"
1: Environment variables: 
1:  LD_LIBRARY_PATH=/home/ilg/.local/xPacks/@xpack-dev-tools/clang/15.0.7-2.1/.content/lib/clang/15.0.7:/home/ilg/.local/xPacks/@xpack-dev-tools/clang/15.0.7-2.1/.content/bin/../lib/x86_64-unknown-linux-gnu:/usr/lib/gcc/x86_64-linux-gnu/7.5.0:/lib/x86_64-linux-gnu:/lib/../lib64:/usr/lib/x86_64-linux-gnu:/lib:/usr/lib
1: Test timeout computed to be: 10000000
1: micro_os_plus::trace::initialize()
1: Marry
1: Bob
1: Sally
1: 
1: Marry
1: Sally
...

There is nothing unusual in this configuration.

[eli-schwartz]

This is not an answer to the question I asked. You elided the focus point of my question and replaced it with an ellipsis.

What I asked:

But I'm curious, how does cmake handle your toolchain if a CMakeLists.txt file uses https://cmake.org/cmake/help/latest/module/CheckCSourceRuns.html

What you responded to:

I'm curious, how does cmake handle your toolchain...

[ilg-ul]

I elided it because in CMake using those checks is not mandatory, and my tests run very well without them, while meson thinks it knows better and mandates these checks, failing to setup my projects.

I'm afraid this thread leads nowhere. The current answer is that the compiler sanity checks cannot be disabled.

[eli-schwartz]

But what is the problem with setting the rpath in LDFLAGS and having it automatically get added to every binary, including both the ones the project builds and the sanity check that meson compiles -- and also the cc.run() programs if a project makes use of them?

[ilg-ul]

what is the problem with setting the rpath in LDFLAGS

The main problem is that this is an extra step that must be done before invoking meson, and this translates into increased complexity.

The definitions for the many build configurations are already complex, with a top package.json, and lots of other platform dependent files in the tests folder. The idea is to implement the whole logic in the build configurations, and parametrise the meson/cmake invocations to support all possible cases.

Since the meson/cmake configurations are side by side, it can be seen that the meson configurations are already more complicated than the cmake ones, and adding extra steps or wrappers simply to compensate for unfriendly design issues is not exactly desirable.

[jpakkane]

What might work is that instead of doing a native build you do a cross build and define an exe wrapper. In that wrapper you can set whatever flags and envvars you want to make things work.

[ilg-ul]

Thank you for the suggestion, but things tend to become more complicated that they should be.

[jpakkane]

Is there any particular reason why you don't set LD_LIBRARY_PATH immediately when doing the configuration step? Why would it need to be delayed until the final step? So something like:

LD_LIBRARY_PATH=/path/to/your/thing CC=<..> CXX=<..> meson setup <other arguments>

FWICT you do know what the value should be for each compiler. Obviously it might also need to be set when compiling and definitely when running tests.

[ilg-ul]

Is there any particular reason why you don't set LD_LIBRARY_PATH immediately when doing the configuration step?

Yes, from my experience with building and using these (many) standalone toolchains, on Linux it is highly recommended to reduce the scope of LD_LIBRARY_PATH to the minimum possible, otherwise it can interfere with the libraries used by the toolchains themselves, which have a similar problem, they have to refer to the shared libraries located in their folders, which are different from the libraries needed by the binaries generated by them, and were copied in local folders from the toolchain used to build the toolchain.

Yes, Linux is a real mess in this regard. On macOS things are much smoother, since the resulting binaries generally have absolute paths to their libraries.

[eli-schwartz]

That is why my suggestion had been to use LDFLAGS to set the rpath.

[ilg-ul]

For those interested, here is a GitHub run with the CI tests for this project:

• https://github.com/micro-os-plus/utils-lists-xpack/actions/runs/4969097441/jobs/8892083056

This is the short list of these tests, since they use only the latest versions of the toolchains. Before project releases, I trigger a different GitHub Actions workflow, which runs with all those many toolchain versions, on even more platforms, currently not available as GitHub runners.

As it can be seen, for the native builds, the meson clang configuration is missing, as being problematic. :-(