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.
