Fixing test failures on macOS
Branko Čibej <[email protected]> Tue, 16 Jun 2026 09:51:13 +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.
--------------pjaSocO7GOl6frejmBPeROWm
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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.
testxlate:
Translation from UTF-7 to UTF-8 converts "Edelwei+AN8-" to "Edelweiß-"
This is a bug in the system libiconv that configure finds by
default. Using a newer version of libiconv fixes the conversion bug
and the test.
testsock: most tests fail
sendfile: all tests fail
The server components of the tests fail with:
apr_socket_bind()->48/Address already in use
even though 'netstat' says that port isn't in use. Fixed by changing
the TCP port used by the tests from 8021 to 8022 or 38021. I see
launchd listening on port 8021 on my Mac and it seems that it's this:
https://apple.stackexchange.com/questions/404346/what-is-intu-ec-client-listening-on-tcp-port-8021#404356
I have no idea why someone over at Apple thinks I need an FTP proxy
hogging my ports. Anyway, I propose to change the test ports to 38021,
that should fix the problems on macOS and not cause any new problems on
other platforms. I hope.
-- Brane
--------------pjaSocO7GOl6frejmBPeROWm
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>
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>
<br>
testxlate:<br>
<blockquote>Translation from UTF-7 to UTF-8 converts "Edelwei+AN8-"
to "Edelweiß-"<br>
<br>
This is a bug in the system libiconv that configure finds by
default. Using a newer version of libiconv fixes the conversion
bug and the test.<br>
</blockquote>
<br>
testsock: most tests fail<br>
sendfile: all tests fail<br>
<blockquote>The server components of the tests fail with:<br>
<blockquote>apr_socket_bind()->48/Address already in use<br>
</blockquote>
even though 'netstat' says that port isn't in use. Fixed by
changing the TCP port used by the tests from 8021 to 8022 or
38021. I see launchd listening on port 8021 on my Mac and it seems
that it's this:<br>
<br>
<a class="moz-txt-link-freetext" href="https://apple.stackexchange.com/questions/404346/what-is-intu-ec-client-listening-on-tcp-port-8021#404356">https://apple.stackexchange.com/questions/404346/what-is-intu-ec-client-listening-on-tcp-port-8021#404356</a><br>
</blockquote>
I have no idea why someone over at Apple thinks I need an FTP proxy
hogging my ports. Anyway, I propose to change the test ports to
38021, that should fix the problems on macOS and not cause any new
problems on other platforms. I hope.<br>
<br>
<br>
-- Brane<br>
<br>
</body>
</html>
--------------pjaSocO7GOl6frejmBPeROWm--