Building swipl on freebsd


I’m currently trying to commit swipl-8.2.3 to freebsd ports, but my patch gets rejected due to the creation of a directory (/usr/local/share/swi-prolog) during build. I run:

cd swipl-devel
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -G Ninja ..

… and the directory appears during ninja. If I add:


… to cmake the problem disappears. I have searched high and low in cmakefiles and some .pl files w/out spotting the reason. I would appreciate some pointers as to what I might do to avoid this directory while keeping INSTALL_DOCUMENTATION=ON.

It is not entirely clear to me what is happening. What I do know is that quite a few of the packages are directly or indirectly needed to build the documentation. To create a normal default build make sure to have the dependencies installed. Just run cmake .. in the build dir again to see what is missing.

It should be investigated exactly which packages are required to build the docs. At the same time it is probably possible to significantly reduce the dependencies for the docs.

As is, install the dependencies or do not build the docs. Note that most of the dependencies are also needed to get version that works as advertised. Building a reduced system typically only makes sense if you want a minimal Prolog system for embedding into some application.

Ok. For the record, I have all dependencies installed beforehand. I will simply disable documentation for now, and then reenable it in the future.

In that case I guess you get some error message during the ninja build? That may help finding out what is missing. It is also possible some dependency is installed, but not found. Try

?- check_installation.

Ninja seems to work fine - I don’t see error messages; when running check_installation I get a few issues - two warnings related to old config storage diretories, and then:

% Checking tcmalloc … not present
Warning: See

Warning: library(bdb) … NOT FOUND
Warning: See

Warning: library(jpl) … NOT FOUND
Warning: See

I should probably look into tcmalloc, but the other two I don’t worry too much about. Swipl as such seems to work fine.

You tried ctest?

Quite important for 24x7 web services on Linux as it wastes a lot less memory then glibc ptmalloc. BSD might have a better default malloc.

bdb and jpl are certainly not vital for building the docs. Little clue …

I ran ctest and it still segfaults on pengines as reported earlier this year by some other user. All other tests run fine when I build “on my own” (simply using cmake/ninja).

When “clean room building” by the freebsd build servers at least one test fails because it accesses files outside of the local build environment established by these servers, so I have diabled tests in official builds.

I looked into tcmalloc, and some guy “out there” reported good performance using jemalloc (default on freebsd) compared to tcmalloc. This seemed speed performance oriented, so I can’t attest to the difference between the two regarding memory usage. At this point I haven’t discovered a freebsd/tcmalloc port, so I might choose to keep it like this at first.

Just referencing the thread: [swi/prolog 8.2.1] : bugs on FreeBSD

I switched to tcmalloc when possible after observing an ever growing amount of wasted (freed and not reused) memory using ptmalloc on SWISH and the webserver. For more info see Poor memory reuse (tcmalloc?)

Yeah, I think I spotted that one at one point. I wont pretend to be an expert on the matter. In some thread on the web, jemalloc was praised for releasing memory back to the system instead of keeping it hanging around forever. I will run some tests to see if jemalloc behaves more like tcmalloc than malloc/Linux version.

I already pushed another commit to get a new patch officially approved, but that wont stop me from improving the port further both when it comes documentation and malloc-implementation.

I finally spotted the existing tcmalloc port and included that as an option enabled by default.

If anyone should happen to know about how to avoid /usr/local/share/swi-prolog, I would still like to know about it!

Ah, Now I got it. It creates the XDG directory for common data because it seems the build is executed by root and /usr/local/share exists and is owned by root. I pushed a fix that ensures this directory is only created if absolute_file_name/3 is asked to find a location for a writable file.

So, the current git version should not show this behavior any longer. For old versions you can hack around by setting the environment variable XDG_DATA_DIRS to a non-existing directory.

Thank you - that did the trick!