swipl-devel icon indicating copy to clipboard operation
swipl-devel copied to clipboard

Specifying CXX breaks package build

Open kamahen opened this issue 1 year ago • 3 comments

The "main" build and package builds use different ways of specifying the compiler, which can result in using different compilers being used and/or the tests not being able to find the test foreign predicates. In particular, the "main" build uses wrap-gcc but the packages use whatever cmake thinks is best (using CC and CXX environment variables). When CC and CXX are specified, cmake test can't find the test foreign predicates.

This presumably could be easily fixed by using wrap-gcc in packages, but I don't understand why specifying CC and CXX prevents ctest test from finding the test foreign predicates.

For -DCMAKE_BUILD_TYPE=Debug, wrap-gcc isn't used, which further complicates things.

My g++ (and gcc) are in /home/peter/.local/gcc-13/bin and reachable by my PATH.

The following has two sections -- with and without -DCMAKE_BUILD_TYPE=Debug and within each section, with and without setting CC and CXX. For each of those, I've put the command line that cmake used for building pl-atom.c and packages/cpp/test_cpp.cpp


DEBUG

CC, CXX aren't set

tests run OK

pl-atom.c: /usr/bin/cc -Isrc -I../src -DCHECK_FORMAT -DO_DEBUG -DO_DEBUG_ATOMGC -O0 -gdwarf-2 -g3 -fPIC -fvisibility=hidden -Wall -fno-strict-aliasing -std=gnu11 -MD -MT src/CMakeFiles/swiplobjs.dir/pl-atom.c.o -MF src/CMakeFiles/swiplobjs.dir/pl-atom.c.o.d -o src/CMakeFiles/swiplobjs.dir/pl-atom.c.o -c ../src/pl-atom.c

packages/cpp/test_cpp: /usr/bin/c++ -Dplugin_test_cpp_EXPORTS -Ipackages/cpp -I../src/os -I../src -DO_DEBUG -O0 -gdwarf-2 -g3 -fPIC -Wall -D__SWI_PROLOG__ -std=c++17 -Wpedantic -MD -MT packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -MF packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o.d -o packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -c ../packages/cpp/test_cpp.cpp

CC, CXX are set:

export CC=$(type -p gcc) export CXX=$(type -p g++)

tests: test cpp:unwrap: received error: plunit_cpp:'unit body'/2: Unknown procedure: plunit_cpp:unwrap/1

pl-atom.c: /home/peter/.local/gcc-13/bin/gcc -Isrc -I../src -DCHECK_FORMAT -DO_DEBUG -DO_DEBUG_ATOMGC -O0 -gdwarf-2 -g3 -fPIC -fvisibility=hidden -Wall -fno-strict-aliasing -std=gnu11 -MD -MT src/CMakeFiles/swiplobjs.dir/pl-atom.c.o -MF src/CMakeFiles/swiplobjs.dir/pl-atom.c.o.d -o src/CMakeFiles/swiplobjs.dir/pl-atom.c.o -c ../src/pl-atom.c

packages/cpp/test_cpp: /home/peter/.local/gcc-13/bin/g++ -Dplugin_test_cpp_EXPORTS -Ipackages/cpp -I../src/os -I../src -DO_DEBUG -O0 -gdwarf-2 -g3 -fPIC -Wall -D__SWI_PROLOG__ -std=c++17 -Wpedantic -MD -MT packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -MF packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o.d -o packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -c ../packages/cpp/test_cpp.cpp

non-DEBUG

CC, CXX aren't set

tests run OK

pl-atom.c: /home/peter/src/swipl-devel/build/src/wrap-gcc -pgo-instrumented /usr/bin/cc

packages/cpp/test_cpp: /usr/bin/c++

CC, CXX are set:

export CC=$(type -p gcc) export CXX=$(type -p g++)

tests: test cpp:unwrap: received error: plunit_cpp:'unit body'/2: Unknown procedure: plunit_cpp:unwrap/1

pl-atom.c: /home/peter/src/swipl-devel/build/src/wrap-gcc -pgo-instrumented /home/peter/.local/gcc-13/bin/gcc -Isrc -I../src -DCHECK_FORMAT -O2 -gdwarf-2 -g3 -fPIC -fvisibility=hidden -Wall -fno-strict-aliasing -fprofile-generate -Wno-maybe-uninitialized -fprofile-dir=/home/peter/src/swipl-devel/build/PGO-data -std=gnu11 -MD -MT src/CMakeFiles/swiplobjs-pgo-instrumented.dir/pl-atom.c.o -MF src/CMakeFiles/swiplobjs-pgo-instrumented.dir/pl-atom.c.o.d -o src/CMakeFiles/swiplobjs-pgo-instrumented.dir/pl-atom.c.o -c ../src/pl-atom.c

packages/cpp/test_cpp: /home/peter/.local/gcc-13/bin/g++ -Dplugin_test_cpp_EXPORTS -Ipackages/cpp -I../src/os -I../src -fPIC -Wall -D__SWI_PROLOG__ -MD -MT packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -MF packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o.d -o packages/cpp/CMakeFiles/plugin_test_cpp.dir/test_cpp.cpp.o -c ../packages/cpp/test_cpp.cpp

kamahen avatar Jan 08 '24 22:01 kamahen

Before each test, I did rm -rf on the build directories.

To determine the command line for compiling, I introduced a syntax error in either pl-atom.c or test_cpp.cpp, which caused cmake to output the command line (is there a better way of doing this?).

kamahen avatar Jan 08 '24 22:01 kamahen

Weird. First of all, wrap-gcc does not change anything. It is just a wrapper for the C compiler when doing a PGO build. It doesn't change which C compiler is called and is not involved in the configure tests. As we only do the PGO build for the core and this is all C11, there is no need to deal with this in packages, C++, etc.

I do quite a lot of compiler switching using CC=.. CXX=.. cmake ... and never experienced any problems. If the compilation works fine and it is only running the tests, I'd first try to figure out what is wrong with the build product. Possibly there is some visibility rule that makes a symbol invisible that should not? It could be a GCC-13 issue. I do not have GCC-13 on my machine. Haven't heard about problems with it though.

JanWielemaker avatar Jan 09 '24 09:01 JanWielemaker

which caused cmake to output the command line (is there a better way of doing this?).

Run ninja -v or look in build.ninja. As this emits a lot of stuff, I normally touch one source file and then run ninja -v. Ninja also comes with a lot of flags and tools that allow inspecting the configuration. I don't know whether inspecting the commands for targets is one of them. Only used the tools to browse the dependency graph.

JanWielemaker avatar Jan 09 '24 09:01 JanWielemaker

I've upgraded my system, and now using gcc etc in the usual place (/use/bin). This has fixed a number of problems, including no need for LD_PRELOAD when running tests with ASAN. So, I'm guessing that the problem was that I had the compiler and runtime libraries in a non-standard place (~/.local) and in some situations that was incompatible with the system compiler/libraries (in /usr).

kamahen avatar Mar 11 '24 17:03 kamahen