On 19. 6. 2026 07:10, Branko Čibej wrote:
On 19. 6. 2026 02:03, Nathan Hartman wrote:
On Thu, Jun 18, 2026 at 1:46 PM Branko Čibej <[email protected]> wrote:
On 16. 6. 2026 09:51, Branko Čibej wrote:
I've been looking at test failures on macOS for the last several
days. These are the failing tests that I see:
testdbd:
Line 211: failed to fetch sqlite3 driver: DSO load failed
I haven't looked closely at this one yet, but since I didn't
point configure at a recent SQLite3 installation, I suspect
it's picking up the system libraries which are known to be
ancient and incomplete. Could also be related to how the
macOS loader searches for loadable modules at runtime.
Might have known. on macOS, System Integrity Protection removes
DYLD_LIBRARY_PATH and similar variables that are considered
dangerous from the environment that we just meticulously set in
the Makefile, But only when you run a shell script ("programs"
generated by libtool are shell scripts), the loader removes .
Because of that, the 'dbm/.libs' and 'dbd/.libs' are never
considered for search by the dynamic loader.
The test works if I `make install` first, because apu_dso_load()
explicitly looks at the install prefix, or if I call the actual
executable in ./libs/testall.
:(
-- Brane
Are you running it from within Apple's Terminal program?
As opposed to running it through some other program, such as an Emacs
shell or whatever, in which case, try running that software from the
Apple terminal.
macOS' SIP treats programs run from the Terminal differently.
I'm running "make check" from the Terminal, yes. I've know about this
issue with DYLD_LIBRARY_PATH etc. since SIP was introduced, it just
slipped my mind. But I've never heard of SIP behaving differently from
the terminal than otherwise.
I can even "fix" this particular test by changing test/Makefile to run
.libs/program directly instead of the libtool-generated ./program. But
that sort of misses the point of using libtool in the first place.
-- Brane
