./configure Not Using the '--with-sqlite' PATH I Told It
(1) By DB (ACB) on 2025-03-18 22:27:30 [link] [source]
I'm not sure what happened.
After a few failed attempts to build the most recent fossil, I had to change the ./configure option from
--with-sqlite=/[$custom]/usr/local to
--with-sqlite=tree and it worked.
I used my fossil build script I'd been using since late 2023 and most recently built fossil after ssh-keygen support was added (thank you Daniel). Version 2.26 [90a52b549f] 2025-01-14 17:16:56 UTC
In my /[$custom]/usr/local/bin I had SQLite version 3.47.0 2024-08-16 18:51:46 which I built last year. In /usr/bin is an older version of sqlite3 which I can't sudo away or replace with a ln to mine. My $PATH includes /[$custom]/usr/local/bin: first.
fossil built properly, but when I ran it...
$ /[$custom]/usr/local/bin/fossil
Unsuitable SQLite version 3.xy.0, must be at least 3.49.0
Abort trap: 6
So I built the latest version, and soon had this installed.
$ /[$custom]/usr/local/bin/sqlite3 version
SQLite version 3.50.0 2025-03-17 15:13:47
Then I built the latest fossil.
My fossil build script used to include this:
time ./configure \
--prefix="$VAR1" \
--with-openssl="$VAR2" \
--with-sqlite="$VAR2" \
--with-zlib="$VAR2"
While it built I could see it found openssl and zlib. It prints this:
Checking for zlib.h...ok
Found zlib.h via -I/[$custom]/usr/local/include
Checking for inflateEnd in z...-lz
Linked to zlib via -L/[$custom]/usr/local/lib
Checking for compressBound in z...-lz
Using -lsqlite3 from /[$custom]/usr/local
Checking for openssl in /[$custom]/usr/local...ok
HTTPS support enabled
But running it gave me the same "Unsuitable SQLite version" error message above. I had to change the --with-sqlite option to tree. Then fossil built and ran.
I’ve seen SQLite is updated quite frequently to fossil’s trunk, so I’m not particularly worried. I checked all of fossil’s source files for '/usr/bin/' to see if it was hardcoded somehow or if there was something I could do.
I noticed the minimum SQLite version was bumped recently so I guess that’s what triggered it. I hadn’t noticed fossil wasn’t using the sqlite3 I built.
Is this an issue with my setup, something in fossil’s build scripts, or?
Thank you.
(2) By Stephan Beal (stephan) on 2025-03-19 10:12:08 in reply to 1 [link] [source]
But running it gave me the same "Unsuitable SQLite version" error message above. I had to change the --with-sqlite option to tree. Then fossil built and ran.
My suspicion is that you're building against the correct one, but because you're linking dynamically to it, you're not running against that one.
After building it, try:
$ ldd fossil
and you might see that it's linking to an sqlite from /usr/lib instead of $custom/usr/local/.
The solution for that is (at least one Linux) to edit your LD_LIBRARY_PATH like you've done for your PATH:
LD_LIBRARY_PATH=$custom/usr/local/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH
If my suspicion about your linking is correct, that will resolve the problem for you.
If it's not correct, please let us know and i'll look into the --with-sqlite support and find out what's going on.
(3) By DB (ACB) on 2025-03-21 21:07:07 in reply to 2 [link] [source]
I don't have ldd. Perhaps because I'm on Darwin?
I tried setting LD_LIBRARY_PATH and exporting it to the environment, but it didn't show up!
My build script has env in it every so often so I can see what's in the environment. And for some strange reason it's not there. I also have lots of printf's throughout, for troubleshooting. So I could see LD_LIBRARY_PATH had no value before I set it, but after assigning it, I could see the variable's value, but for some strange reason when env ran, it wasn't there! But the other environment variables I set were!
One of them is CFLAGS in which I set DSQLITE_MAX_LENGTH based on a forum post I read awhile ago regarding adding large files to a repo, since I figured I'd bump into that issue some day.
Please excuse my naiveté in compiling software. I do have a LDFLAGS=-L/$custom/usr/local/lib which I exported and shows up in env. But I have no idea why I don't see LD_LIBRARY_PATH after setting it.
(4) By Stephan Beal (stephan) on 2025-03-21 21:21:22 in reply to 3 [link] [source]
Perhaps because I'm on Darwin?
Ah, that does its whole own thing, far removed from my ken. We'll need to get input from someone who uses that platform.
I tried setting LD_LIBRARY_PATH and exporting it to the environment, but it didn't show up!
i've no clue whether Macs use LD_LIBRARY_PATH. i assumed, based on your system paths, that you were using Linux or BSD or the like.
On my system --with-sqlite=/path/to/sqlite behaves as expected but my /path/to/sqlite contains sqlite3.c (as opposed to a precompiled copy) and fossil is using that sqlite3.c, which eliminates any link-time issues. So try...
./configure --with-sqlite=/top/dir/of/sqlite/src/tree
noting that it won't work unless that dir is a sufficiently recent sqlite, namely something very close to the trunk. If you're using an actual fossil checkout of the sqlite tree, run this in that tree first:
$ ./configure
$ make sqlite3.c
(5) By DB (ACB) on 2025-03-21 22:13:35 in reply to 4 [link] [source]
Thank you Stephan, that worked. Although when I first tried it on trunk's tip, I got the same errors & warnings Kirill did. So I went back to a version from around the 18th. Like him, I have LibreSSL installed as my default OpenSSL.
(6) By Richard Hipp (drh) on 2025-03-22 08:52:04 in reply to 3 [link] [source]
The command on Mac is:
otool -L ./fossil
I have two macs that I use daily, on x64 and another ARM. Using the very latest sources, and building according to the step-by-step instructions seen at https://fossil-scm.org/home/wiki?name=Release+Build+How-To, I get:
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
System libraries only, since I statically link against both SQLite and OpenSSL.
Running "fossil version -v" shows me:
This is fossil version 2.26 [50ff741f6f] 2025-03-21 23:29:54 UTC Compiled on Mar 22 2025 04:47:13 using clang-14.0.0 (clang-1400.0.29.202) (64-bit) SQLite 3.50.0 2025-03-16 00:13:29 18bda13e19 SSL (OpenSSL 3.4.1 11 Feb 2025) zlib 1.2.11, loaded 1.2.11
(7) By Martin Gagnon (mgagnon) on 2025-03-22 14:15:25 in reply to 3 [link] [source]
In my environment on Mac, I link with openssl dynamically from Homebrew package manager.
The configure seems to have find it automatically.
otool -L fossil give me:
$ otool -L /usr/local/bin/fossil /usr/local/bin/fossil: /usr/local/lib/libfuse.2.dylib (compatibility version 12.0.0, current version 12.9.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/opt/openssl@3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/local/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
I think homebrew do some magics with symlinks in /usr/local/opt.
My fossil binary will only run in my Mac (or may be another with with homebrew configured similarly).
(8) By Joye ayyaan (Joye1978) on 2025-03-22 20:46:33 in reply to 7 [source]
Based on the otool output you provided, here are a few key points:
1-Dynamic Linking with Homebrew OpenSSL: Your fossil binary is dynamically linked to OpenSSL from Homebrew (/usr/local/opt/openssl@3/lib/libssl.3.dylib and /usr/local/opt/openssl@3/lib/libcrypto.3.dylib). This means that the binary expects OpenSSL to be available in the same location, which is typically where Homebrew installs it. The path /usr/local/opt/openssl@3/ is a symlink that points to the actual location where OpenSSL is installed.
2-System Libraries: It's also linked to some standard system libraries like libiconv, libz, and libSystem.B.dylib. These are generally available on macOS by default, so they shouldn't cause any compatibility issues when running on another macOS machine.
3-Cross-System Compatibility: Since fossil is linked dynamically with the Homebrew version of OpenSSL, it will only run on a system where Homebrew has installed OpenSSL in the same location (/usr/local/opt/openssl@3/). If you try to run this binary on a different system (even another Mac), the binary may fail to start unless that system also has Homebrew and the same version of OpenSSL installed at the same location.
4-Solution for Portability: If you need to make the binary more portable, one solution is to statically link the OpenSSL libraries into the binary when you build it. This would bundle OpenSSL with the binary, making it less dependent on the specific environment where it was built. Alternatively, you could create a script or package that ensures the correct version of OpenSSL is installed on the target system (e.g., through Homebrew or another method).
I think , your fossil binary will likely only work on macOS systems that have Homebrew installed and have OpenSSL installed in the same way. To make it more portable, consider static linking or packaging dependencies.
Joye
Founder at
arbeitszeitrechnerr.de