Undeclared identifier 'H_SAVE_FP'

Help!
1

Trying to build SWI-PROLOG using cmake as described here

on my Mac Mini (arm64), but running the ‘ninja‘ command, it seems to get stuck on the use of the ‘undeclared identifier H_SAVE_FP‘ relative to the file
../swipl-devel/packages/libedit/libedit4pl.c:2111:24
I’m sorry if this issue has already been treated before, I wasn’t able to find anything regarding it. I just need the graphical tracer and xpce library that do not come with the stable home-brew installation.

2

Thanks for reporting. Pushed a work-around.

3

I was about to comment on the same issue. On MacOS, using Homebrew for installing packages, there is a message on some packages, including libedit:

==> Caveats
libedit is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

For compilers to find libedit you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/libedit/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/libedit/include"

For pkgconf to find libedit you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/libedit/lib/pkgconfig"

Until now, I have been apparently building against the MacOS provided libedit. It does not even have H_SAVE_FP.

How can one permanently enable finding homebrew packages? At least on my system, this worked:

a file homebrew.cmake:

set(HOMEBREW_PREFIX "/opt/homebrew"
    CACHE PATH "Path to Homebrew installation")

set(CMAKE_C_COMPILER "/usr/bin/gcc")
set(CMAKE_CXX_COMPILER "/usr/bin/g++")

set(CMAKE_PREFIX_PATH
    "${HOMEBREW_PREFIX}"
    # These libraries are keg-only and not loaded into
    # the root prefix by default (to avoid clashes).
    "${HOMEBREW_PREFIX}/opt/libedit"
    "${HOMEBREW_PREFIX}/opt/zlib"
)

list(TRANSFORM CMAKE_PREFIX_PATH APPEND "/include"
     OUTPUT_VARIABLE CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES)
set(CMAKE_C_STANDARD_INCLUDE_DIRECTORIES "${CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES}")

set(CMAKE_FIND_FRAMEWORK NEVER)
set(CMAKE_FIND_APPBUNDLE NEVER)

set(CMAKE_FIND_USE_CMAKE_SYSTEM_PATH FALSE)
set(CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH FALSE)

assuming that I have installed both zlib and libedit with homebrew; then adding the following to the cmake invocation:

cmake -Wno-dev \
   -DCMAKE_TOOLCHAIN_FILE=cmake/homebrew.cmake \
   -DCMAKE_INSTALL_PREFIX="$HOME"
   # and so on
4

That might be more elegant than what is in cmake/port/Darwin.cmake. This way to select a source for the MacOS dependencies is

 cmake -DMACOSX_DEPENDENCIES_FROM=Source

Where Source is one of

  • Homebrew
  • Macports
  • A prefix directory holding the all dependencies

If nothing is specified it will try to find Macports, then Homebrew and then give up.

Feel free to do some cleanup/merge/…

5

Actually, forgot the push :frowning: Current master branch should compile fine again.

6

This is in fact not true I think? On my system, when nothing is specified, I get the MacOS libedit, despite having also a homebrew libedit. When I do for example man 3 editline, I don’t even see H_SAVE_HP in the list of operations (but it no longer breaks since your last commit to packages/libedit)

If this would work it would be of course better. But if I run:

cmake -Wno-dev \
   -DMACOSX_DEPENDENCIES_FROM=Homebrew
   # and so on

then I see in build/CMakeCache.txt:

//Path to a file.
LIBEDIT_INCLUDE_DIR:PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include

//Path to a library.
LIBEDIT_LIBRARIES:FILEPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libedit.tbd

When I run it with my homebrew.cmake file, I get:

//Path to a file.
LIBEDIT_INCLUDE_DIR:PATH=/opt/homebrew/opt/libedit/include

//Path to a library.
LIBEDIT_LIBRARIES:FILEPATH=/opt/homebrew/opt/libedit/lib/libedit.dylib

But, obviously, in my homebrew.cmake, I have hardcoded references to the “keg-only” libraries I have happened to install with homebrew. I don’t know how to turn this into a generic solution :-/

7

Good question. If I look at my default build (getting the deps from Macports), it gets all dependencies from Macports. If I use -DMACOSX_DEPENDENCIES_FROM=Homebrew though, it seems to get the few things I have installed from Homebrew indeed from Homebrew, but the rest comes from Macports. That seems a bad idea.

8

OK, I took a look at cmake/ports/Darwin.cmake.

I can see what it tries to do and I can confirm that for some reason, on my computer, it doesn’t do it correctly. H_SAVE_FP helped me notice the problem.

The homebrew.cmake I posted above solves a problem that only I seem to have. Please ignore it.

Sorry for the noise.

9

That seems to hold here as well. If I select Homebrew, I think it should not get its dependencies from Macports as a fallback. It is a bit more debatable whether or not it should use system libraries as fallback?

10

Not for all dependencies. Some are so different from the Linux alternative that it gets brittle, and so easy to get with Macports/Homebrew

11

True. I think the only problematic one is libreadline though. This is the editline readline replacement on MacOS, which was useless for us. As we dropped the readline package, this no longer matters. The others are libedit and zlib, for which both the OS and Macports/Homebrew version are fine.