Re: Fixing test failures on macOS
Branko Čibej <[email protected]> Fri, 19 Jun 2026 07:10:29 +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. --------------01zm0Z9A8CLxph7NXbFwsVmN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. -- Brane --------------01zm0Z9A8CLxph7NXbFwsVmN 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 19. 6. 2026 02:03, Nathan Hartman wrote:<br> </div> <blockquote type="cite" cite="mid:CAJT2EHopcA-TMH7YZWrG71qGqgcaueP5zsoRShKn3+mvPW161g@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div> <div>On Thu, Jun 18, 2026 at 1:46 PM Branko Čibej <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <div> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <div>On 16. 6. 2026 09:51, Branko Čibej wrote:<br> </div> <blockquote type="cite"> 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> </div> </blockquote> </div> </div> </div> <div> <div dir="auto"><br> </div> <div dir="auto"><br> </div> <div dir="auto">Are you running it from within Apple's Terminal program?</div> <div dir="auto"><br> </div> <div dir="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="auto"><br> </div> <div dir="auto">macOS' SIP treats programs run from the Terminal differently.</div> </div> </blockquote> <br> <br> 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.<br> <br> -- Brane<br> <br> </body> </html> --------------01zm0Z9A8CLxph7NXbFwsVmN--