Re: Fixing test failures on macOS

Branko Čibej <[email protected]> Thu, 18 Jun 2026 19:46:49 +0200
Newsgroups	gmane.comp.apache.apr.devel
Organization	The Apache Software Foundation
Message-ID	<[email protected]>
This is a multi-part message in MIME format.
--------------aM5AjM7Q6JM292Krw0RyT7jx
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------aM5AjM7Q6JM292Krw0RyT7jx
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 16. 6. 2026 09:51, Branko Čibej
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      I'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'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.</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 ("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.<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>
  </body>
</html>

--------------aM5AjM7Q6JM292Krw0RyT7jx--