Getting further. One issue remains that I forgot to include in my prior email..
Issue 3: When compiling Quad_FIO.cc, the following error occurs:
Quad_FIO.cc:2166:11: error: no viable conversion from '__bind<const int &,
sockaddr *, unsigned long>'
to 'const int'
2166 | const int err = bind(fd, &addr.addr, sizeof(addr.inet));
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning and 1 error generated.
There's a namespace conflict between the C++ bulit-in std::bind and the socket
syscall bind(). This is fixed by changing the line to:
2166 | const int err = ::bind(fd, &addr.addr, sizeof(addr.inet));
I happened to find this solution by looking at the entire GNU APL source for
use of bind(), and found that other calls to bind() when used in the context of
sockets was coded in this manner.
Once I applied this change, compilation and build of SVN 2096 completed
successfully.
Apologies for not including that issue in my prior report...
- Paui
>
>
> On Aug 24, 2026, at 6:51 AM, Dr. Jürgen Sauermann <mail@jürgen-sauermann.de>
> wrote:
>
> Hi Paul,
>
> thanks for the detailed diffs -- both issues found and fixed.
>
> 1) Quad_FIO.cc: get_random()'s MORE_ERROR() streamed a raw ssize_t
> into UCS_string's operator<<, ambiguous on clang because Darwin's
> int64_t is `long long`, a genuinely distinct type from `long` even
> though both are 64 bits there. On Linux/glibc, int64_t (our
> ShapeItem) IS `long`, so operator<<(ShapeItem) matches exactly and
> the ambiguity never shows up there. Rather than add a new
> operator<<(long) overload to UCS_string.hh -- which you rightly
> flagged as needing platform-conditionalizing, since it would collide
> with the existing ShapeItem overload on Linux -- I cast the one
> affected value to ShapeItem at its call site instead; that's an exact
> match on every platform, no header change needed. Checked the rest of
> the tree for the same pattern; that was the only instance.
>
> 2) rval.def: B_stim/A_stim/X_stim were bare, unquoted macro
> arguments, stringified via # in Quad_RVAL.cc. GCC happens to tolerate
> the lone ¯ glyph that every row there relies on; clang rejects it
> outright ("unexpected character <U+00AF>"), which is why it failed on
> almost every line. Applied your fix close to the original: quoted all
> three fields as ordinary C strings and changed the macro to pass them
> through directly instead of stringifying.
>
> Verified both against the regression suite (test3/test4, 0 errors)
> and directly against ⎕RVAL's own output and testcases/AllPrimitives.tc
> (0 errors), the fuzzer that actually consumes that table.
>
> Fixed in SVN 2096. Please svn up and retry; let us know if anything
> else comes up.
>
> Best regards,
> Jürgen
>
> PS: Both of these were found and fixed with the help of Claude Code
> (https://savannah.gnu.org/projects/apl).
>
> On 8/21/26 17:12, Paul Rockwell wrote:
>> SVN 2093 - still having issues.
>>
>> Looks like new errors on macOS causing Quad_FIO.cc to fail compliation:
>>
>> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I
>> /Users/paulrockwell/Documents/apl/trunk -O2 -Wno-narrowing
>> -I/opt/local/include -std=gnu++17 -I /Users/paulrockwell/Documents/apl/trunk
>> -MT apl-Quad_FIO.o -MD -MP -MF .deps/apl-Quad_FIO.Tpo -c -o apl-Quad_FIO.o
>> `test -f 'Quad_FIO.cc' || echo './'`Quad_FIO.cc
>> In file included from Quad_FIO.cc:69:
>> In file included from ./StateIndicator.hh:33:
>> ./Prefix.hh:31:1: warning: struct 'DerivedFunction' was previously declared
>> as a class; this is valid, but may result in linker errors under the
>> Microsoft C++ ABI [-Wmismatched-tags]
>> 31 | struct DerivedFunction;
>> | ^
>> ./DerivedFunction.hh:39:7: note: previous use is here
>> 39 | class DerivedFunction : public Function
>> | ^
>> ./Prefix.hh:31:1: note: did you mean class here?
>> 31 | struct DerivedFunction;
>> | ^~~~~~
>> | class
>> Quad_FIO.cc:2114:11: error: no viable conversion from '__bind<const int &,
>> sockaddr *, unsigned long>' to 'const int'
>> 2114 | const int err = bind(fd, &addr.addr, sizeof(addr.inet));
>> | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Quad_FIO.cc:3598:22: error: use of overloaded operator '<<' is ambiguous
>> (with operand types 'UCS_string' and 'const ssize_t' (aka 'const long'))
>> 3597 | MORE_ERROR() << "⎕FIO[60]: short read from /dev/urandom ("
>> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 3598 | << bytes << " of " << len << " bytes)";
>> | ^ ~~~~~
>> ./UCS_string.hh:290:17: note: candidate function
>> 290 | UCS_string & operator <<(int num)
>> | ^
>> ./UCS_string.hh:294:17: note: candidate function
>> 294 | UCS_string & operator <<(unsigned long num)
>> | ^
>> ./UCS_string.hh:298:17: note: candidate function
>> 298 | UCS_string & operator <<(unsigned int num)
>> | ^
>> ./UCS_string.hh:302:17: note: candidate function
>> 302 | UCS_string & operator <<(ShapeItem num)
>> | ^
>> ./UCS_string.hh:311:17: note: candidate function
>> 311 | UCS_string & operator <<(unsigned long long num)
>> | ^
>> ./UCS_string.hh:492:17: note: candidate function
>> 492 | UCS_string & operator << (double num);
>> | ^
>> 1 warning and 2 errors generated.
>> make[3]: *** [apl-Quad_FIO.o] Error 1
>> make[2]: *** [all-recursive] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>>
>>
>>> On Aug 21, 2026, at 5:01 AM, Dr. Jürgen Sauermann
>>> <mail@jürgen-sauermann.de> wrote:
>>>
>>> Hi Paul,
>>>
>>> Thanks for the detailed reports -- both issues found and fixed.
>>>
>>> 1) The .so/*.dylib glob: the fix in SVN 2090 relied on an unmatched
>>> shell glob being left as a literal, non-existent filename (sh/bash's
>>> behaviour), which 'test -f' then quietly skips. zsh's default NOMATCH
>>> option instead aborts the whole command at glob-expansion time, before
>>> the loop body ever runs, which is what your manual zsh test caught.
>>> Replaced the glob in both src/native/Makefile.am and
>>> src/emacs_mode/Makefile.am with 'find', which never goes through shell
>>> glob-expansion at all and so behaves identically under sh, bash, and
>>> zsh alike.
>>>
>>> (Separately: the "SVN 2090 still doesn't work" you first hit was our
>>> own process gap, not yours -- Makefile.in is checked into SVN
>>> precisely so a plain './configure' works without autoconf/automake
>>> installed, but the SVN 2090 commit only regenerated and committed
>>> src/emacs_mode/Makefile.am, not the Makefile.in generated from it, so
>>> your checkout's Makefile.in still had the old *.so-only glob baked in
>>> regardless of 'svn up'. 'autoreconf --install --force' worked around
>>> it by regenerating Makefile.in locally. This time both Makefile.am and
>>> Makefile.in are going out together, so no autoreconf is needed -- just
>>> the normal 'svn up', './configure', 'make', 'make install' sequence.)
>>>
>>> 2) sem_timedwait(): you found a real one. Darwin's <semaphore.h>
>>> declares sem_init()/sem_wait()/sem_trywait()/sem_post() for unnamed
>>> semaphores but never declares sem_timedwait() at all -- unlike the
>>> existing HAVE_SEM_INIT case (which is a runtime limitation, already
>>> worked around), this is a compile-time absence, and it broke Archive.cc
>>> too since Quad_PLOT.hh is pulled in transitively via SystemVariable.def
>>> regardless of --without-x/--without-gtk3.
>>>
>>> Added a HAVE_SEM_TIMEDWAIT configure check (same pattern as
>>> HAVE_SEM_INIT) and a portable fallback in Quad_PLOT.hh: when
>>> sem_timedwait() isn't declared, sem_wait_safe() polls sem_trywait()
>>> against the same deadline instead, sleeping briefly between polls. Same
>>> outcomes (^C / timeout / error), same messages, no GTK/XCB/X11 dependency
>>> either way -- it's used regardless of which of those are configured in.
>>>
>>> Fixed in SVN 2092. Please svn up, then ./configure, make, make install
>>> again as usual (no autoreconf needed this time); let us know if
>>> anything else comes up.
>>>
>>> Best regards,
>>> Jürgen
>>>
>>> PS: Both of these were found and fixed with the help of Claude Code
>>> (https://savannah.gnu.org/projects/apl).
>>>
>>>
>>> On 8/20/26 21:07, Paul Rockwell wrote:
>>>> I spoke too soon. I recompiled against the wrong SVN.
>>>>
>>>> Whaever the changes that involve sem_timedwait in Quad_Plot.hh and the GTK
>>>> and XCB modules, they've broken APL builds on macOS even if you've told
>>>> configure to remove x11 and gtk3. As an example
>>>> Quad_PLOT.hh is being included in Archive.cc. That breaks the
>>>> compilation:
>>>>
>>>> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I
>>>> /Users/paulrockwell/Documents/apl/trunk -O2 -Wno-narrowing
>>>> -I/opt/local/include -std=gnu++17 -I
>>>> /Users/paulrockwell/Documents/apl/trunk -MT apl-Archive.o -MD -MP -MF
>>>> .deps/apl-Archive.Tpo -c -o apl-Archive.o `test -f 'Archive.cc' || echo
>>>> './'`Archive.cc
>>>> In file included from Archive.cc:85:
>>>> ./Quad_PLOT.hh:103:13: error: use of undeclared identifier 'sem_timedwait'
>>>> 103 | if (sem_timedwait(sema, &deadline) == 0) return
>>>> PLOT_WAIT_OK;
>>>> | ^~~~~~~~~~~~~
>>>> In file included from Archive.cc:91:
>>>> In file included from ./StateIndicator.hh:33:
>>>> ./Prefix.hh:31:1: warning: struct 'DerivedFunction' was previously
>>>> declared as a class; this is valid, but may result in linker errors under
>>>> the Microsoft C++ ABI [-Wmismatched-tags]
>>>> 31 | struct DerivedFunction;
>>>> | ^
>>>> ./DerivedFunction.hh:39:7: note: previous use is here
>>>> 39 | class DerivedFunction : public Function
>>>> | ^
>>>> ./Prefix.hh:31:1: note: did you mean class here?
>>>> 31 | struct DerivedFunction;
>>>> | ^~~~~~
>>>> | class
>>>> 1 warning and 1 error generated.
>>>>
>>>> If you try commenting out Quad_PLOT.hh, the following error occurs:
>>>>
>>>> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I
>>>> /Users/paulrockwell/Documents/apl/trunk -O2 -Wno-narrowing
>>>> -I/opt/local/include -std=gnu++17 -I
>>>> /Users/paulrockwell/Documents/apl/trunk -MT apl-Archive.o -MD -MP -MF
>>>> .deps/apl-Archive.Tpo -c -o apl-Archive.o `test -f 'Archive.cc' || echo
>>>> './'`Archive.cc
>>>> In file included from Archive.cc:91:
>>>> In file included from ./StateIndicator.hh:33:
>>>> ./Prefix.hh:31:1: warning: struct 'DerivedFunction' was previously
>>>> declared as a class; this is valid, but may result in linker errors under
>>>> the Microsoft C++ ABI [-Wmismatched-tags]
>>>> 31 | struct DerivedFunction;
>>>> | ^
>>>> ./DerivedFunction.hh:39:7: note: previous use is here
>>>> 39 | class DerivedFunction : public Function
>>>> | ^
>>>> ./Prefix.hh:31:1: note: did you mean class here?
>>>> 31 | struct DerivedFunction;
>>>> | ^~~~~~
>>>> | class
>>>> In file included from Archive.cc:561:
>>>> ./SystemVariable.def:88:10: error: use of undeclared identifier 'Quad_PLOT'
>>>> 88 | sf_def(Quad_PLOT, "PLOT", "Plot a Value" )
>>>> | ^
>>>> 1 warning and 1 error generated.
>>>>
>>>>
>>>> Seems like there's a bigger issue here. The changes made that introduced
>>>> the use of sem_timedwait() (which seemed to be introduced to fix other
>>>> problems related to the windows that were created by either GTK3 or XCB
>>>> use in ⎕PLOT) seem to be incompatible with platforms other than Linux.
>>>> And right now there doesn't seem to be a way around it. It appears that
>>>> the definition of the functions in Quad_PLOT.hh may have to be
>>>> conditionalized based upon whether the X11/GTK/XCB libraries are actually
>>>> present (indicating that you're going to use an X11 window). Seems to me
>>>> that you don't need to go through all the semaphore wait code if you have
>>>> a platform that isn't using X11. Or figure out a way to fix the issue that
>>>> you've found without having to use the Linux-only sem_timedwait() so that
>>>> other platforms can continue to use XCB or GTK3.
>>>>
>>>> - Paul
>>>>
>>>>
>>>>> On Aug 20, 2026, at 2:01 PM, Paul Rockwell <[email protected]> wrote:
>>>>>
>>>>> I wasn't able to get by the error until I performed an autoreconf
>>>>> --install --force which rebuilt Makefile.in from your updated
>>>>> Makefile.am. I'm now getting past this particular issue issue, but
>>>>> encountering another one:
>>>>>
>>>>> g++ -DHAVE_CONFIG_H -I. -I.. -Wall -O2 -I ./sql -I
>>>>> /Users/paulrockwell/Documents/apl/trunk -O2 -Wno-narrowing
>>>>> -I/opt/local/include -std=gnu++17 -I
>>>>> /Users/paulrockwell/Documents/apl/trunk -MT apl-Plot_xcb.o -MD -MP -MF
>>>>> .deps/apl-Plot_xcb.Tpo -c -o apl-Plot_xcb.o `test -f 'Plot_xcb.cc' ||
>>>>> echo './'`Plot_xcb.cc
>>>>> In file included from Plot_xcb.cc:42:
>>>>> ./Quad_PLOT.hh:103:13: error: use of undeclared identifier 'sem_timedwait'
>>>>> 103 | if (sem_timedwait(sema, &deadline) == 0) return
>>>>> PLOT_WAIT_OK;
>>>>> | ^~~~~~~~~~~~~
>>>>> Plot_xcb.cc:192:22: warning: variable length arrays in C++ are a Clang
>>>>> extension [-Wvla-cxx-extension]
>>>>> 192 | xcb_char2b_t xcb_str[string_length + 10];
>>>>> | ^~~~~~~~~~~~~~~~~~
>>>>> Plot_xcb.cc:192:22: note: initializer of 'string_length' is not a
>>>>> constant expression
>>>>> Plot_xcb.cc:191:14: note: declared here
>>>>> 191 | const size_t string_length = strlen(string);
>>>>> | ^
>>>>> Plot_xcb.cc:1315:27: warning: variable length arrays in C++ are a Clang
>>>>> extension [-Wvla-cxx-extension]
>>>>> 1315 | uint8_t scanline[3*width + 10];
>>>>> | ^~~~~~~~~~~~
>>>>> Plot_xcb.cc:1315:29: note: initializer of 'width' is not a constant
>>>>> expression
>>>>> 1315 | uint8_t scanline[3*width + 10];
>>>>> | ^
>>>>> Plot_xcb.cc:1228:20: note: declared here
>>>>> 1228 | const unsigned int width = geo_x + geo_w + geo_x;
>>>>> | ^
>>>>> Plot_xcb.cc:1281:5: warning: variable 'file_bytes' set but not used
>>>>> [-Wunused-but-set-variable]
>>>>> 1281 | int file_bytes = 0;
>>>>> | ^
>>>>> 3 warnings and 1 error generated.
>>>>> make[3]: *** [apl-Plot_xcb.o] Error 1
>>>>> make[2]: *** [all-recursive] Error 1
>>>>> make[1]: *** [all-recursive] Error 1
>>>>> make: *** [all] Error 2
>>>>> paulrockwell@Upstairs trunk %
>>>>>
>>>>>
>>>>> I'm running configure with the following options:
>>>>>
>>>>> ./configure --without-gtk3 CXXFLAGS="-O2 -Wno-narrowing
>>>>> -I/opt/local/include -std=gnu++17" LDFLAGS="-L/opt/local/lib"
>>>>>
>>>>> I have X11, gtk3, and and other open-source libraries used by GNU APL
>>>>> installed via MacPorts (an alternative to Homebrew). They reside in
>>>>> /opt/local/include and /opt/local/lib - so I needed to add them to the
>>>>> library and header search lists.
>>>>>
>>>>> The SVN of APL that I have installed for my day-to-day use (SVN 2034)
>>>>> compiled fine without this use of undeclared identifier error. Just
>>>>> reverted back to SVN 2034 and re-built to verify.
>>>>>
>>>>> A diff shows lots of changes in Plot_xcb.cc and Quad_Plot.hh - which I
>>>>> suspect are the reasons behing why this error is now appearing.
>>>>>
>>>>> I've been able to work around this by adding --without-x to my configure
>>>>> command"
>>>>>
>>>>> ./configure --without-x --without-gtk3 CXXFLAGS="-O2 -Wno-narrowing
>>>>> -I/opt/local/include -std=gnu++17" LDFLAGS="-L/opt/local/lib"
>>>>>
>>>>>
>>>>> Some additional research indicates that sem_timedwait does not exist on
>>>>> macOS.
>>>>>
>>>>> - Paul
>>>>>
>>>>>
>>>>>> On Aug 20, 2026, at 12:55 PM, Paul Rockwell <[email protected]> wrote:
>>>>>>
>>>>>> SVN 2090 still doesn't work. Manually executing the statement that you
>>>>>> changed when using the macOS standard shell zsh:
>>>>>>
>>>>>> % for so in .libs/*.so .libs/*.dylib ; do
>>>>>> echo "$so"
>>>>>> done
>>>>>> zsh: no matches found: .libs/*.so
>>>>>>
>>>>>> Running it in the Bourne shell works:
>>>>>>
>>>>>> % sh
>>>>>> sh-3.2$ for so in .libs/*.so .libs/*.dylib ; do
>>>>>> > echo "$so"
>>>>>> > done
>>>>>> .libs/*.so
>>>>>> .libs/libemacs.0.dylib
>>>>>> .libs/libemacs.dylib
>>>>>> sh-3.2$
>>>>>>
>>>>>> Running this under Bash also fails but with a different issue:
>>>>>>
>>>>>> bash
>>>>>> bash-5.3$ for so in .libs/*.so .libs/*dylib ; do
>>>>>> > echo "$$so"
>>>>>> > done
>>>>>> 59622so
>>>>>> 59622so
>>>>>> 59622so
>>>>>>
>>>>>> The following does work under bash, and the Bourne sh, but not zsh:
>>>>>>
>>>>>> % bash
>>>>>> bash-5.3$ for so in .libs/*.so .libs/*dylib ; do echo "$so"; done
>>>>>> .libs/*.so
>>>>>> .libs/libemacs.0.dylib
>>>>>> .libs/libemacs.dylib
>>>>>> % exit
>>>>>> % sh
>>>>>> sh-3.2$ for so in .libs/*.so .libs/*dylib ; do echo "$so"; done
>>>>>> .libs/*.so
>>>>>> .libs/libemacs.0.dylib
>>>>>> .libs/libemacs.dylib
>>>>>>
>>>>>>
>>>>>> - Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 20, 2026, at 12:17 PM, Dr. Jürgen Sauermann via Bugs and
>>>>>>> suggestions for GNU APL <[email protected]> wrote:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>> thanks for the follow-up. Same class of bug, just in a different
>>>>>>> subdirectory this time: src/emacs_mode/Makefile.am's all-local step had
>>>>>>> the identical .libs/*.so-only glob (used to copy the freshly built
>>>>>>> libemacs next to the apl binary) -- on MacOS libtool builds
>>>>>>> libemacs.dylib
>>>>>>> instead, so the glob was again left as a literal, non-existent filename,
>>>>>>> and the failed 'test -f' aborted the build right there, again with no
>>>>>>> error text of its own.
>>>>>>>
>>>>>>> Fixed in SVN 2090 -- now globs both *.so and *.dylib in
>>>>>>> src/emacs_mode/Makefile.am as well, and can no longer abort the build
>>>>>>> either way. Please svn up and retry; let us know if anything else comes
>>>>>>> up.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Jürgen
>>>>>>>
>>>>>>> PS: This error was fixed with the help of Claude Code
>>>>>>> (https://savannah.gnu.org/projects/apl).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/20/26 15:16, M.Hall wrote:
>>>>>>>> Thank you! It gets much farther along before the next error:
>>>>>>>> ===
>>>>>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../..
>>>>>>>> -Wno-deprecated-declarations -g -O2 -I
>>>>>>>> /Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk -MT VersionCommand.lo
>>>>>>>> -MD -MP -MF .deps/VersionCommand.Tpo -c VersionCommand.cc -o
>>>>>>>> VersionCommand.o >/dev/null 2>&1
>>>>>>>> /bin/sh ../../libtool --tag=CXX --mode=link g++
>>>>>>>> -Wno-deprecated-declarations -g -O2 -I
>>>>>>>> /Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk -export-dynamic -o
>>>>>>>> libemacs.la -rpath /usr/local/lib/apl DefCommand.lo emacs.lo
>>>>>>>> FnCommand.lo FnTagCommand.lo FollowCommand.lo GetVarCommand.lo
>>>>>>>> HelpCommand.lo Listener.lo LockWrapper.lo network.lo
>>>>>>>> NetworkConnection.lo RunCommand.lo SicCommand.lo SiCommand.lo
>>>>>>>> SendCommand.lo SystemFnCommand.lo SystemVariableCommand.lo
>>>>>>>> TcpListener.lo TempFileWrapper.lo TraceData.lo UnixSocketListener.lo
>>>>>>>> util.lo VariablesCommand.lo VersionCommand.lo -lpcre2-32 -lpng -lz
>>>>>>>> -lfftw3 -ldl -lm -lpthread
>>>>>>>> libtool: link: g++ -r -keep_private_externs -nostdlib -o
>>>>>>>> .libs/libemacs.0.dylib-master.o .libs/DefCommand.o .libs/emacs.o
>>>>>>>> .libs/FnCommand.o .libs/FnTagCommand.o .libs/FollowCommand.o
>>>>>>>> .libs/GetVarCommand.o .libs/HelpCommand.o .libs/Listener.o
>>>>>>>> .libs/LockWrapper.o .libs/network.o .libs/NetworkConnection.o
>>>>>>>> .libs/RunCommand.o .libs/SicCommand.o .libs/SiCommand.o
>>>>>>>> .libs/SendCommand.o .libs/SystemFnCommand.o
>>>>>>>> .libs/SystemVariableCommand.o .libs/TcpListener.o
>>>>>>>> .libs/TempFileWrapper.o .libs/TraceData.o .libs/UnixSocketListener.o
>>>>>>>> .libs/util.o .libs/VariablesCommand.o .libs/VersionCommand.o
>>>>>>>> libtool: link: g++ -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
>>>>>>>> .libs/libemacs.0.dylib .libs/libemacs.0.dylib-master.o
>>>>>>>> /usr/local/lib/libpcre2-32.dylib /usr/local/lib/libpng16.dylib -lz
>>>>>>>> /usr/local/lib/libfftw3.a -ldl -lm -lpthread -g -O2 -pthread
>>>>>>>> -install_name /usr/local/lib/apl/libemacs.0.dylib
>>>>>>>> -compatibility_version 1 -current_version 1.0
>>>>>>>> libtool: link: (cd ".libs" && rm -f "libemacs.dylib" && ln -s
>>>>>>>> "libemacs.0.dylib" "libemacs.dylib")
>>>>>>>> libtool: link: ar cr .libs/libemacs.a DefCommand.o emacs.o
>>>>>>>> FnCommand.o FnTagCommand.o FollowCommand.o GetVarCommand.o
>>>>>>>> HelpCommand.o Listener.o LockWrapper.o network.o NetworkConnection.o
>>>>>>>> RunCommand.o SicCommand.o SiCommand.o SendCommand.o SystemFnCommand.o
>>>>>>>> SystemVariableCommand.o TcpListener.o TempFileWrapper.o TraceData.o
>>>>>>>> UnixSocketListener.o util.o VariablesCommand.o VersionCommand.o
>>>>>>>> libtool: link: ranlib .libs/libemacs.a
>>>>>>>> libtool: link: ( cd ".libs" && rm -f "libemacs.la" && ln -s
>>>>>>>> "../libemacs.la" "libemacs.la" )
>>>>>>>> make[3]: *** [all-local] Error 1
>>>>>>>> make[3]: Leaving directory
>>>>>>>> `/Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk/src/emacs_mode'
>>>>>>>> make[2]: *** [all-recursive] Error 1
>>>>>>>> make[2]: Leaving directory
>>>>>>>> `/Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk/src'
>>>>>>>> make[1]: *** [all-recursive] Error 1
>>>>>>>> make[1]: Leaving directory
>>>>>>>> `/Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk'
>>>>>>>> make: *** [all] Error 2
>>>>>>>> make: Leaving directory
>>>>>>>> `/Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk'
>>>>>>>> SVN/trunk $
>>>>>>>>
>>>>>>>> $ svn info
>>>>>>>> Path: .
>>>>>>>> Working Copy Root Path: /Volumes/ARCHIVE/Language/APL/gnu-apl/SVN/trunk
>>>>>>>> URL: svn://svn.savannah.gnu.org/apl/trunk
>>>>>>>> Relative URL: ^/trunk
>>>>>>>> Repository Root: svn://svn.savannah.gnu.org/apl
>>>>>>>> Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
>>>>>>>> Revision: 2089
>>>>>>>> Node Kind: directory
>>>>>>>> Schedule: normal
>>>>>>>> Last Changed Author: j_sauermann
>>>>>>>> Last Changed Rev: 2089
>>>>>>>> Last Changed Date: 2026-08-20 07:21:59 -0500 (Thu, 20 Aug 2026)
>>>>>>>>
>>>>>>>> $ c++ --version
>>>>>>>> Apple clang version 17.0.0 (clang-1700.0.13.5)
>>>>>>>> Target: arm64-apple-darwin24.6.0
>>>>>>>> Thread model: posix
>>>>>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Aug 18, 2026 at 10:30 AM Dr. Jürgen Sauermann
>>>>>>>> <mail@jürgen-sauermann.de> wrote:
>>>>>>>> Hi Mike,
>>>>>>>>
>>>>>>>> Thanks for the report -- found it. src/native/Makefile.am's all-local
>>>>>>>> step copies the freshly-built native-function libraries next to the
>>>>>>>> apl binary so the interpreter can be tested from the build tree without
>>>>>>>> a prior 'make install'. That step globbed .libs/*.so only; on MacOS
>>>>>>>> libtool builds .dylib instead, so the glob matches nothing, is left as
>>>>>>>> a literal (non-existent) filename, and the resulting failed 'test -f'
>>>>>>>> aborts the whole build right there -- which is exactly why your
>>>>>>>> transcript shows a fully successful compile/link/ranlib/symlink
>>>>>>>> sequence for lib_template_OP2 immediately followed by 'all-local]
>>>>>>>> Error 1' with no error text of its own: the failure is in that copy
>>>>>>>> step, not in anything you pasted above it.
>>>>>>>>
>>>>>>>> Fixed at SVN 2087 -- now globs both *.so and *.dylib, and
>>>>>>>> can no longer abort the build either way. Please svn up and retry;
>>>>>>>> let us know if anything else comes up.
>>>>>>>>
>>>>>>>> Jürgen
>>>>>>>>
>>>>>>>> PS: Claude Code found and fixed this one.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 8/18/26 16:13, M.Hall wrote:
>>>>>>>>> I get a build error with the latest SVN (happened last week, too).
>>>>>>>>> Used to build ok earlier in the year. No changes to compiler; only
>>>>>>>>> security updates to macOS 15.7. Have removed existing svn/trunk
>>>>>>>>> directory and tried a new svn clone. Same result.
>>>>>>>>>
>>>>>>>>> $ make clean
>>>>>>>>> $ svn up
>>>>>>>>> $ ./configure --without-x
>>>>>>>>> $ make -w
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
>>>>>>>>> -I. -I../.. -I ./.. -g -O2 -g -O2 -I
>>>>>>>>> /Volumes/WORK/Language/APL/gnu-apl/SVN/trunk -MT
>>>>>>>>> lib_template_OP2_la-template_OP2.lo -MD -MP -MF
>>>>>>>>> .deps/lib_template_OP2_la-template_OP2.Tpo -c -o
>>>>>>>>> lib_template_OP2_la-template_OP2.lo `test -f 'template_OP2.cc' ||
>>>>>>>>> echo './'`template_OP2.cc
>>>>>>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I ./.. -g -O2 -g
>>>>>>>>> -O2 -I /Volumes/WORK/Language/APL/gnu-apl/SVN/trunk -MT
>>>>>>>>> lib_template_OP2_la-template_OP2.lo -MD -MP -MF
>>>>>>>>> .deps/lib_template_OP2_la-template_OP2.Tpo -c template_OP2.cc
>>>>>>>>> -fno-common -DPIC -o .libs/lib_template_OP2_la-template_OP2.o
>>>>>>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I ./.. -g -O2 -g
>>>>>>>>> -O2 -I /Volumes/WORK/Language/APL/gnu-apl/SVN/trunk -MT
>>>>>>>>> lib_template_OP2_la-template_OP2.lo -MD -MP -MF
>>>>>>>>> .deps/lib_template_OP2_la-template_OP2.Tpo -c template_OP2.cc -o
>>>>>>>>> lib_template_OP2_la-template_OP2.o >/dev/null 2>&1
>>>>>>>>> mv -f .deps/lib_template_OP2_la-template_OP2.Tpo
>>>>>>>>> .deps/lib_template_OP2_la-template_OP2.Plo
>>>>>>>>> /bin/sh ../../libtool --tag=CXX --mode=link g++ -I ./.. -g -O2
>>>>>>>>> -g -O2 -I /Volumes/WORK/Language/APL/gnu-apl/SVN/trunk -avoid-version
>>>>>>>>> -export-dynamic -o lib_template_OP2.la -rpath /usr/local/lib/apl
>>>>>>>>> lib_template_OP2_la-template_OP2.lo -lpcre2-32 -lpng -lz -lfftw3
>>>>>>>>> -ldl -lm -lpthread
>>>>>>>>> libtool: link: g++ -r -keep_private_externs -nostdlib -o
>>>>>>>>> .libs/lib_template_OP2.dylib-master.o
>>>>>>>>> .libs/lib_template_OP2_la-template_OP2.o
>>>>>>>>> libtool: link: g++ -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
>>>>>>>>> .libs/lib_template_OP2.dylib .libs/lib_template_OP2.dylib-master.o
>>>>>>>>> /usr/local/lib/libpcre2-32.dylib /usr/local/lib/libpng16.dylib -lz
>>>>>>>>> /usr/local/lib/libfftw3.a -ldl -lm -lpthread -g -O2 -g -O2
>>>>>>>>> -pthread -install_name /usr/local/lib/apl/lib_template_OP2.dylib
>>>>>>>>> libtool: link: ar cr .libs/lib_template_OP2.a
>>>>>>>>> lib_template_OP2_la-template_OP2.o
>>>>>>>>> libtool: link: ranlib .libs/lib_template_OP2.a
>>>>>>>>> libtool: link: ( cd ".libs" && rm -f "lib_template_OP2.la" && ln -s
>>>>>>>>> "../lib_template_OP2.la" "lib_template_OP2.la" )
>>>>>>>>> make[3]: *** [all-local] Error 1
>>>>>>>>> make[3]: Leaving directory
>>>>>>>>> `/Volumes/WORK/Language/APL/gnu-apl/SVN/trunk/src/native'
>>>>>>>>> make[2]: *** [all-recursive] Error 1
>>>>>>>>> make[2]: Leaving directory
>>>>>>>>> `/Volumes/WORK/Language/APL/gnu-apl/SVN/trunk/src'
>>>>>>>>> make[1]: *** [all-recursive] Error 1
>>>>>>>>> make[1]: Leaving directory
>>>>>>>>> `/Volumes/WORK/Language/APL/gnu-apl/SVN/trunk'
>>>>>>>>> make: *** [all] Error 2
>>>>>>>>> make: Leaving directory
>>>>>>>>> `/Volumes/WORK/Language/APL/gnu-apl/SVN/trunk'
>>>>>>>>>
>>>>>>>>> $ svn info
>>>>>>>>> Path: .
>>>>>>>>> Working Copy Root Path: /Volumes/WORK/Language/APL/gnu-apl/SVN/trunk
>>>>>>>>> URL: svn://svn.savannah.gnu.org/apl/trunk
>>>>>>>>> Relative URL: ^/trunk
>>>>>>>>> Repository Root: svn://svn.savannah.gnu.org/apl
>>>>>>>>> Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
>>>>>>>>> Revision: 2086
>>>>>>>>> Node Kind: directory
>>>>>>>>> Schedule: normal
>>>>>>>>> Last Changed Author: j_sauermann
>>>>>>>>> Last Changed Rev: 2086
>>>>>>>>> Last Changed Date: 2026-08-18 08:23:05 -0500 (Tue, 18 Aug 2026)
>>>>>>>>>
>>>>>>>>> $ g++ --version
>>>>>>>>> Apple clang version 17.0.0 (clang-1700.0.13.5)
>>>>>>>>> Target: arm64-apple-darwin24.6.0
>>>>>>>>> Thread model: posix
>>>>>>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>> --
>>>>>>>>> Mike Hall
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mike Hall
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
