Re: Fixing test failures on macOS
Branko Čibej <[email protected]> Fri, 19 Jun 2026 07:22:18 +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. --------------Fl1q2y0gQPt8LuXj0XHEw0Z0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------Fl1q2y0gQPt8LuXj0XHEw0Z0 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 07:10, Branko Čibej wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <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> </blockquote> <br> <br> 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.<br> <br> -- Brane<br> <br> </body> </html> --------------Fl1q2y0gQPt8LuXj0XHEw0Z0--