Re: Fixing test failures on macOS

--00000000000035bb0d06549007a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 18, 2026 at 1:46=E2=80=AFPM Branko =C4=8Cibej <[email protected]=
> wrote:

> On 16. 6. 2026 09:51, Branko =C4=8Cibej 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 runti=
me.
>
>
>
> Might have known. on macOS, System Integrity Protection removes
> DYLD_LIBRARY_PATH and similar variables that are considered dangerous fro=
m
> 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 executabl=
e
> 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.

--00000000000035bb0d06549007a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div>On Thu, Jun 18, 2026 at 1:46=E2=80=AFPM Branko =C4=8Cibej &lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;=
 wrote:<br></div><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 16. 6. 2026 09:51, Branko =C4=8Cibej
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      I&#39;ve been looking at test failures on macOS for the last several
      days. These are the failing tests that I see:<br>
      <br>
      testdbd:<br>
      <blockquote>Line 211: failed to fetch sqlite3 driver: DSO load
        failed<br>
        <br>
        I haven&#39;t looked closely at this one yet, but since I didn&#39;=
t
        point configure at a recent SQLite3 installation, I suspect it&#39;=
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.</blockquote>
    </blockquote>
    <br>
    <br>
    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 (&quot;programs&quot; ge=
nerated
    by libtool are shell scripts), the loader removes . Because of that,
    the &#39;dbm/.libs&#39; and &#39;dbd/.libs&#39; are never considered fo=
r search by
    the dynamic loader.<br>
    <br>
    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.<br>
    <br>
    :(<br>
    <br>
    -- Brane<br>
    <br>
  </div>

</blockquote></div></div></div><div><div dir=3D"auto"><br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Are you running it from within Apple&#39=
;s Terminal program?</div><div dir=3D"auto"><br></div><div dir=3D"auto">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=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">macOS&#39; SIP treats =
programs run from the Terminal differently.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>
</div>

--00000000000035bb0d06549007a5--