I regret bothering you so soon after the 9.2.2 upgrade per https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277550 But there are a few changes between 9.2.2 and 9.2.4, extract from https://www.swi-prolog.org/ChangeLog?branch=stable&from=9.2.2&to=9.2.4 that affect many that are working with large numbers or security would be: Bug fixes/operational enhancement FIXED: unifiable/3 internal consistency Unifiable did not correctly handle stack resizing. This is detected when running using chk_secure. Not sure whether it can also cause real issues, but the new code is simpler and safe. FIXED: Memory leak in string_bytes/3. ENHANCED: Use temprary malloc API for bignum arithemetic ENHANCED: Keep small bignums on the stack ENHANCED: Improve memory reuse after writing huge integers. Enhancements for development ENHANCED: coverage/2: analyze and annotate included files. The coverage analyzer now deals with files that are included. Files that are included multiple times in different modules get their numbers aggregated. Security enhancement MODIFIED: library(http/http_load) to verify certificates This library allows for loading files from http/https URLs. It used to skip certificate checking. Checking is now enabled and the Option argument may be used to disable it (using the cert_verify_hook option). To provide context I use prolog "executables" as long running management systems and I'm bringing in http to acquire updates and use signing verification extensively. :)
Keeping me on my toes Dewayne! :o) I'll take a look at it.
(In reply to Nikolaj Thygesen from comment #1) Thanks Nikolay. While we were sleeping 9.2.5 came out. Though one of MY drivers was the absence of max_integer in current_prolog_flag in 9.0.4 which was there in 8.4.3 and remains in the doc. So I'm kinda hoping it returned in 9.2.5... As a precaution I've just logged a bug https://swi-prolog.discourse.group/t/max-integer-seems-to-be-on-holiday-mia-from-current-prolog-flag-v9-0-4/7476 so there may be a 9.2.6 shortly??? Though of course the workaround is to simply fake the call and return 9223372036854775807.
Created attachment 257562 [details] Update swipl to 9.2.9 This updates swipl to 9.2.9 rather than 9.2.4 as requested.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=487e19f62088ac38d9c31661a72428f5ff6339c3 commit 487e19f62088ac38d9c31661a72428f5ff6339c3 Author: Wen Heping <wen@FreeBSD.org> AuthorDate: 2025-02-25 02:35:01 +0000 Commit: Wen Heping <wen@FreeBSD.org> CommitDate: 2025-02-25 02:36:10 +0000 lang/swipl: Update to 9.2.9 PR: 279048 Reported by: dewayne@heuristicsystems.com.au Approved by: maintainer lang/swipl/Makefile | 5 ++--- lang/swipl/distinfo | 6 +++--- lang/swipl/pkg-plist | 12 +++++++----- 3 files changed, 12 insertions(+), 11 deletions(-)
(In reply to commit-hook from comment #4) I'm thrilled to report: # swipl ?- process_create('/sbin/sysctl',["-n","kern.osreldate"],[stdout(pipe(Out))]), read_line_to_string(Out,X), close(Out), current_prolog_flag(version,Y),format("OS version=~w, swipl version=~w~n",[X,Y]). OS version=1402501, swipl version=90209 :) Apart from the minor points below, I greatly appreciate the work that has clearly gone into this port; and its value to me. So to the minor points: 1. My package initially failed to build due to duplicate and missing files. pkg-static: duplicate file listing: /usr/local/lib/cmake/swipl/SWIPLTargets-release.cmake, ignoring So I compared against https://cgit.freebsd.org/ports/tree/lang/swipl/pkg-plist and noticed a few differences between my pkg-plist and that one. I suspect that you may have corrected the pkg-plist after I'd pulled it. 2. Because I dont use odbc option (its set to NO during config), the package failed with /usr/portswrk/usr/ports/local/swipl/work/stage/usr/local/lib/swipl/library/ext/odbc/INDEX.pl:No such file or directory pkg-static: Unable to access file /usr/portswrk/usr/ports/local/swipl/work/stage/usr/local/lib/swipl/library/ext/odbc/odbc.pl:No such file or directory Removing these files allowed the package to complete. Observations during the build. a) This was a common message. I suppose that swipl devs needs to correct? "CMake Deprecation Warning at src/CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 3.10 will be removed from a future version of CMake." FYI: I'm using # cmake --version cmake version 3.31.5 b) Perhaps we need to add to "CFLAGS+= -Wno-dev" to suppress CMake Warning (dev) at cmake/QLF.cmake:75 (install): Policy CMP0177 is not set: install() DESTINATION paths are normalized. Run "cmake --help-policy CMP0177" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): cmake/QLF.cmake:102 (add_swipl_target) src/CMakeLists.txt:328 (add_qcompile_target) This warning is for project developers. Use -Wno-dev to suppress it. Failed component - uuid segfaults. This has been a problem since swip 8.x (7?), so I've worked around it. I've tried ktracing but the cause was elusive. ?- uuid(U,[version(1)]). SWI-Prolog [thread 1 (main) at Sat Mar 1 07:44:09 2025]: received fatal signal 11 (segv) Segmentation fault Have anyone a functioning uuid/2? On 9.0.4, when misc/ossp-uuid is NOT included, uuid/1 and uuid/2 with version(4) works, ?- uuid(D). D = '5a7d4436-b978-4b11-c5ff-5f8472f8ac38'. ?- uuid(D,[version(1)]). ERROR: Domain error: `uuid_options' expected, found `[version(1)]' ERROR: In: ... Interestingly uuid_property/2 works in all cases. I expect that there's an interaction between /usr/local/lib/libossp-uuid.so.16.0.22 and its swipl interface that disagree (?) PS I also have swipl running on HardenedBSD :)
Created attachment 258270 [details] Properly handle build options This patch addresses the build time option issues only. I tested the other options as well and spotted some issues especially when it came to THREADED.
I mentioned the "cmake --help-policy CMP0177" issue on the swipl mailinglist, as it was already reported on Mac and some Linux distro. Hopefully it gets fixed upstream, as it seems like a trivial change... also, it relates to freebsd using a newer cmake, than what the swipl project appears to be using. As for the uuid issue(s) - they bother me as well, and I did play around with a number of fixes, but none of them worked.
(In reply to Nikolaj Thygesen from comment #7) Thank-you very much. :) I only build with threaded so didn't notice. ;) but its good to have consistency.
It seems our cmake issues have gained a bit of traction - Jan@swipl has pushed some files to git, so perhaps in the near future we'll get rid of these warnings.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d50591dae361d3b1fa666fb7a33203d07abaa299 commit d50591dae361d3b1fa666fb7a33203d07abaa299 Author: Nikolaj Thygesen <mailinglist@diamondbox.dk> AuthorDate: 2025-04-02 07:33:41 +0000 Commit: Wen Heping <wen@FreeBSD.org> CommitDate: 2025-04-02 07:36:32 +0000 lang/swipl: Fix pkg-plist when build with options PR: 279048 Reported by: Nikolaj Thygesen <mailinglist@diamondbox.dk> Approved by: maintainer lang/swipl/Makefile | 1 + lang/swipl/pkg-plist | 320 +++++++++++++++++++++++++-------------------------- 2 files changed, 161 insertions(+), 160 deletions(-)
Seems it could build on i386 system now, shall we remove "BROKEN_i386" ?
(In reply to wen from comment #11) Excellent on both counts. :) Though a reminder that I've been running swipl on i386 since I started with swipl (because then most of my machines were i386). But I have modified the Makefile since the 7.x.y, mainly because I only use the cli and don't use gpl stuff. And I should restate that even though I customise the Makefile, I would still be running 8 at best without your support/maintenance efforts :) And yes, I even ran swipl as process 1 (init). Though I can't reduce the dependencies to less than /usr/local/bin/swipl: libstdthreads.so.0 => /usr/lib/libstdthreads.so.0 (0x16b519fe8000) libswipl.so.9 => /usr/local/lib/swipl/lib/amd64-freebsd/libswipl.so.9 (0x16b51a2f2000) libc.so.7 => /lib/libc.so.7 (0x16b51bae9000) libthr.so.3 => /lib/libthr.so.3 (0x16b51addc000) libz.so.6 => /lib/libz.so.6 (0x16b51c729000) libdl.so.1 => /usr/lib/libdl.so.1 (0x16b51c8fe000) libm.so.5 => /lib/libm.so.5 (0x16b51d8a5000) librt.so.1 => /lib/librt.so.1 (0x16b51e4a1000) [vdso] (0x16b518c32000) or on hardenedbsd /usr/local/bin/swipl: libstdthreads.so.0 => /usr/lib/libstdthreads.so.0 (0x80106a000) libswipl.so.9 => /usr/local/lib/swipl/lib/amd64-freebsd/libswipl.so.9 (0x80106f000) libthr.so.3 => /lib/libthr.so.3 (0x80124e000) librt.so.1 => /lib/librt.so.1 (0x80127b000) libm.so.5 => /lib/libm.so.5 (0x801284000) libexecinfo.so.1 => /lib/libexecinfo.so.1 (0x8012c0000) libc.so.7 => /lib/libc.so.7 (0x8012c6000) libz.so.6 => /lib/libz.so.6 (0x8015ae000) libdl.so.1 => /usr/lib/libdl.so.1 (0x8015c9000) libelf.so.2 => /lib/libelf.so.2 (0x8015cd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8015e3000) [vdso] (0x7ffffffff000) why? Having a process doing little more than keeping tty's running or waiting for a shutdown request seemed superfluous ;) (And for the os guys reading :), yes, init_script and init_exec are in the wrong order in init.c too) Jan is very receptive to changes, even when specific to our libc. A change was required as yaml used the atom e as an exponent. The change was available via git and a few months later the change was released. I think we've made the right choice with swipl 8^D
As per Jan, yes, he is indeed receptive, and supposedly he has a fix for our cmake issues on git. I just prefer to go with official releases myself, so I'll wait for a new one. @i386: I'm down with enabling i386 support if it builds. AFAIR it was related to some clang/atomics not being supported on old HW. In any case that would be an issue only in multithreaded environments.