Building swipl on MacOS 15.5 (arm64)

Hi,

I’m currently trying to build a PGO version of swipl of a macOS 15.5 arm-based system. My original aim was to build a custom configuration of swipl, but since I encountered an error I tried going back to building the latest master branch of swipl-devel.

The main interest is in a gcc-14 homebrew-based PGO build, but just for the sake of it I tried using the system clang as well. Here are the results:

clang normal build configuration:
cmake -G Ninja ..

clang PGO build configuration:
cmake -DCMAKE_BUILD_TYPE=PGO -G Ninja ..

gcc-14 PGO build configuration:
eval "$(/opt/homebrew/bin/brew shellenv)"
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk MACOSX_DEPLOYMENT_TARGET=15.5 CFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk -mmacosx-version-min=15.5 CXXFLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk -mmacosx-version-min=15.5
cmake -DCMAKE_BUILD_TYPE=PGO -DCMAKE_C_COMPILER=gcc-14 -DCMAKE_CXX_COMPILER=g++-14 -G Ninja ..

  • Using the system clang, the build and tests are ok
  • Using the system clang with PGO, there is a build error

[1850/2663] Generating ../PGO-data/swipl.profdata FAILED: [code=127] PGO-data/swipl.profdata /Users/nicola/swipl-devel/build/PGO-data/swipl.profdata cd /Users/nicola/swipl-devel/build/src && LLVM_PROFDATA-NOTFOUND merge -output=/Users/nicola/swipl-devel/build/PGO-data/swipl.profdata /Users/nicola/swipl-devel/build/PGO-data/*.profraw /bin/sh: LLVM_PROFDATA-NOTFOUND: command not found ninja: build stopped: subcommand failed.
perhaps due to some misconfiguration on my side, I am still a newbie on macOS. It seems that some llvm binaries are not being found.

  • GCC PGO (gcc-14 installed via homebrew, alongside all the needed dependencies stated in swipl’s documentation): the build is ok, though for each TU there is this annoying warning: [1845/2664] Building C object src/CMakeFiles/swiplobjs-pgo-instrumented.dir/pl-wam.c.o cc1: note: '-g3' is not supported by the debug linker in use (set to 2), but I don’t think it has any impact. However, when running ctest -j14 I get an error on one of the tests:

`% [72/279] cpp:malloc ..libc++abi: terminating due to uncaught exception of type std::bad_alloc: std::bad_alloc

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 0.07 sec

The following tests FAILED:
49 - cpp:cpp (Subprocess aborted)
Errors while running CTest

Sorry for the long writeup, but I think all this information might be useful in figuring out what is going on here. I’m open to do some more tests on this machine.

Thanks

1 Like

Thanks for the writeup. There is one data point missing: gcc without PGO, although I doubt the ctest failure is due to PGO. There is not much point in trying to get PGO working with clang. It used to work, but actually makes things slower :frowning:

There is some point using gcc, though not that much. clang and gcc are much closer wrt the Prolog performance on Arm than on Intel and the gain by PGO on arm is smaller. I don’t have the latest figures precisely in mind, but I think the gcc+PGO version is some 10-15% faster than the clang version. The difference is 30-40% on Intel.

I can’t say much about the C++ test. It passes with AddressSanitizer enabled on Linux.

If the cpp test is the only failure I think you can fairly safely use the gcc+PGO version. If you want to fix it, compile for debugging or, probably better, using AddressSanitizer. See CMAKE.md.

I consider the -g3 issue more a gcc issue. It is hard-coded in cmake/BuildType.cmake. We could do a little hacking to make this dynamic if this persists.

Hi Jan,

I can run non-PGO gcc, though as you noted it’s probably not dissimilar. The main reason I have for using gcc is that all the rest of my dependencies are compiled using gcc. That said, I do have an asan build target as well, so I’m glad to test that configuration too. I could probably patch -g3, but that’s lower priority for me as well.

In the meantime, I was trying to get the GCC+PGO build closer to the actual configuration I want, which is similar to
cmake -DCMAKE_BUILD_TYPE=PGO -DCMAKE_C_COMPILER=gcc-14 -DCMAKE_CXX_COMPILER=g++-14 "-DSWIPL_PACKAGE_LIST=clib;table;libedit" -DSWIPL_PACKAGES=FALSE -DINSTALL_DOCUMENTATION=FALSE -DMULTI_THREADED=FALSE -G Ninja ..
which instead errors at the final QLF compilation phase with

[609/609] QLF compile library
ERROR: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:65:
ERROR:    source_sink `library(http/http_open)' does not exist
Warning: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:65:
Warning:    Goal (directive) failed: prolog_pack:use_module(library(http/http_open))
ERROR: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:66:
ERROR:    source_sink `library(http/json)' does not exist
Warning: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:66:
Warning:    Goal (directive) failed: prolog_pack:use_module(library(http/json))
ERROR: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:67:
ERROR:    source_sink `library(http/http_client)' does not exist
Warning: /Users/nicola/swipl-devel/gcc-pgo/home/library/prolog_pack.pl:67:
Warning:    Goal (directive) failed: prolog_pack:use_module(library(http/http_client),[])
ERROR: /Users/nicola/swipl-devel/gcc-pgo/home/library/dialect/sicstus/timeout.pl:39:
ERROR:    source_sink `library(time)' does not exist
Warning: /Users/nicola/swipl-devel/gcc-pgo/home/library/dialect/sicstus/timeout.pl:39:
Warning:    Goal (directive) failed: timeout:use_module(library(time))

When I cloned swipl-devel I used --recursive and this downloaded several packs, but I guess this is due to the setting of only a couple of packs. Curiously, on linux with 9.3.25 I see the same errors and warnings, but the build carries on normally with

[10/11] Install the project...
-- Install configuration: "PGO"

I’m a bit unsure how to solve this

Pushed 2793ca547c3b185f50d2ce803c582874fc583b70 to stop installing the two involved libraries if dependencies are missing. In general, this is hard. There are so many possible configuration options. We’d need something more declarative than cumbersome CMake if()…endif() :frowning:

On Linux, I now get a clean build and install for

cmake -DCMAKE_BUILD_TYPE=PGO -DSWIPL_PACKAGE_LIST="clib;table;libedit" \
	-DSWIPL_PACKAGES=FALSE -DMULTI_THREADED=FALSE \
	-G Ninja ..

edit: Oops, typo. Also needs bd98d9559393b74742e617efbf3a193fb3547bb8 :frowning:

Thanks, I will try!

Hi,

I tried this on both linux and macOS and the patches do work