Hi, I confirm the following patch (according to your hints) makes GCL 2.7 successfully built on macOS 15 x86 using Apple clang compiler:
--- a/gcl/h/386-macosx.h
+++ b/gcl/h/386-macosx.h
@@ -132,7 +132,7 @@ if (realpath (buf, fub) == 0) {
\
#define UC(a_) ((ucontext_t *)a_)
#define SF(a_) ((siginfo_t *)a_)
-#define FPE_CODE(i_,v_) make_fixnum(FFN(fSfpe_code)(*(fixnum
*)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mxcsr))
+#define FPE_CODE(i_,v_) make_fixnum((fixnum)FFN(fSfpe_code)(*(fixnum
*)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mxcsr))
#define FPE_ADDR(i_,v_) make_fixnum(UC(v_)->uc_mcontext->__fs.__fpu_fop ?
UC(v_)->uc_mcontext->__fs.__fpu_ip : (fixnum)SF(i_)->si_addr)
#define FPE_CTXT(v_) list(3,make_fixnum((fixnum)&UC(v_)->uc_mcontext->__ss), \
make_fixnum((fixnum)&UC(v_)->uc_mcontext->__fs.__fpu_stmm0), \
* * *
Having GCL 2.7 buildable by default Apple compiler will ease the users who wants
to build GCL from sources with customized options. For the MacPorts package, I
still think MacPorts GCC 13 is a good option, because so far I can use it to
build GCL even in macOS 10.10 (perhaps 10.9 also works).
--Chun
On 01/05/25 01:08, Camm Maguire wrote:
> Greetings!
>
> Yes, please place (fixnum) before FFN(fSfpe_code... as in h/linux.h:
>
> #define FPE_CODE(i_,v_) make_fixnum((fixnum)FFN(fSfpe_code)(*(fixnum
> *)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mxcsr))
>
> and let me know if it works, and I'll commit.
>
> All these FPE_ macros will have to be adjusted for arm, or disabled.
>
> Question -- are apple clang 14/16 identical to those found in Debian?
>
> Regarding the arm build, both apple clang 14 and homebrew gcc 14 are
> available on the mac mini arm I am investigating. There seems to be a
> fundamental difference between arm and x86 versions of this compiler.
> Ideally I would like to make them the same with some missing compiler
> flag. But as it stands, both 'cc' version 14 will not process correctly
> calls through a generic function pointer, e.g. (object(*)()), even when
> std=gnu17 is set. At a minimum, variadic functions require a prototype
> (object(*)(object,...)). Calls through the first(second) to targets of
> the second(first) type both fail.
>
> This paradigm is used extensively in the code. It can be addressed, but
> not trivially. I am almost at the point where I can load the lsp source
> files and save saved_pre_gcl. There is of course no debugger, so printf
> debugging only.... If you know of any way these compilers can be
> instructed to use the older C paradigm for now, please let me know.
>
> This issue, together with the arm warnings you sent earlier, all fall
> under the topic 'C23', referring to the new standardization of the
> language. I have created a branch c23, and pushed edits clearing your
> compiler warnings to it. This is only a partial work, as GCL produced C
> code also needs addressing. Eventually all these function pointers need
> the correct prototypes. But it should be possible for now to compile
> under the older paradigm still with some flag, and I think it would be
> prudent for us to get that working first, and then c23 later.
>
> Take care,
>
> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes:
>
>> Unfortunately the building of latest gcl27 (master) on macOS 14 and macOS 15
>> are
>> both failed at the following compilation error: (it looks like an easy type
>> conversion issue?)
>>
>> :info:build /usr/bin/clang -DHAVE_CONFIG_H -I. -I./h -I h -I
>> /usr/include/tirpc -I/opt/local/include
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -pipe -Os
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch x86_64
>> -fsigned-char -pipe -fcommon -fno-builtin-malloc -fno-builtin-free -fno-PIE
>> -fno-pie -fno-PIC -fno-pic -std=gnu17 -Wall -Wno-builtin-requires-header
>> -Wno-empty-body -Wno-self-assign -Wno-unused-but-set-variable
>> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -fbracket-depth=512
>> -Wno-incomplete-setjmp-declaration -m64 -I/opt/local/include
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -O3
>> -fomit-frame-pointer -I o -MT o/usig.o -MD -MP -MF $depbase.Tpo -c -o
>> o/usig.o
>> o/usig.c &&\
>> :info:build mv -f $depbase.Tpo $depbase.Po
>> :info:build o/usig.c:237:36: error: incompatible pointer to integer
>> conversion
>> initializing 'fixnum' (aka 'long') with an expression of type 'object' (aka
>> 'union lispunion *') [-Wint-conversion]
>> :info:build 237 |
>> ifuncall3(sSfloating_point_error,FPE_CODE(i,v),FPE_ADDR(i,v),FPE_CTXT(v));
>> :info:build | ^~~~~~~~~~~~~
>> :info:build ./h/config.h:135:25: note: expanded from macro 'FPE_CODE'
>> :info:build 135 | #define FPE_CODE(i_,v_)
>> make_fixnum(FFN(fSfpe_code)(*(fixnum
>> *)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mxcsr))
>> :info:build |
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> :info:build ./h/../h/fixnum.h:36:44: note: expanded from macro 'make_fixnum'
>> :info:build 36 | #define make_fixnum(a_) ({register fixnum
>> _q1=(a_);register
>> object _q3;\
>> :info:build | ^ ~~~~
>> :info:build 1 error generated.
>> :info:build make[1]: *** [o/usig.o] Error 1
>> :info:build make[1]: Leaving directory
>> `/opt/local/var/macports/build/_Users_binghe_Lisp_macports-gcl_lang_gcl27/gcl27/work/gcl-2.7.1'
>>
>> Note that on macOS 13 the default C compiler is Apple clang 14.0.0 (which is
>> successfully in building GCL 2.7), while on both macOS 14 and 15 the
>> compiler is
>> Apple clang 16.0.0. I believe the above error will show up too if the
>> building
>> process on ARM64 macOS can reach this far.
>>
>> --Chun
>>
>> On 28/04/25 06:09, Camm Maguire wrote:
>>> Greetings! I've pushed a --disable-libboot configure option to master
>>> you might want to try out. Still looking for the right incantation to
>>> make it work as it does elsewhere, but this requires deep knowledge for
>>> the mac.
>>>
>>> Take care,
>>>
>>> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes:
>>>
>>>> Greetings,
>>>>
>>>> I just tried building gcl27 in my macOS 12 VM, and it failed showing the
>>>> same
>>>> issues as in macOS 13:
>>>>
>>>> :info:build echo "(system:save-system \"unixport/gcl0\")" | cat
>>>> unixport/cinit.lisp - | unixport/saved_pre_gcl
>>>> :info:build
>>>> dlopen(/opt/local/var/macports/build/_Users_binghe_Lisp_macports-gcl_lang_gcl27/gcl27/work/gcl-2.7.1/unixport/libboot.so,
>>>> 0x0009): symbol not found in flat namespace (_Cnil_body)
>>>> :info:build dlsym(0x0, gcl_init_boot): invalid handle
>>>> :info:build Segmentation violation: c stack ok:signalling errorSegmentation
>>>> violation: c stack ok:signalling error
>>>> :info:build Unrecoverable error: Segmentation violation..
>>>> :info:build /bin/sh: line 1: 55292 Done echo
>>>> "(system:save-system \"unixport/gcl0\")"
>>>> :info:build 55293 | cat unixport/cinit.lisp -
>>>> :info:build 55294 Abort trap: 6 | unixport/saved_pre_gcl
>>>> :info:build make[1]: *** [unixport/gcl0] Error 134
>>>>
>>>> Note that, I have tried to use either Apple clang 13 and MacPorts GCC 13,
>>>> but
>>>> the error outputs are identical. Therefore I think the above issue with
>>>> libboot.so is more like an issue with Apple's new linker, which even the
>>>> MacPorts GCC must also use.
>>>>
>>>> --Chun
>>>>
>>>> On 25/04/25 02:15, Camm Maguire wrote:
>>>>> Greetings, and once again, thank you so very much for being the 'point
>>>>> of the spear' with macports!
>>>>>
>>>>> Please enlighten me a little regarding the pull request process. My
>>>>> crude understanding is that we build fine on macos 10 (catalina), you in
>>>>> addition have tested successfully on macos 11 (Big sur) as noted in your
>>>>> request, and we fail at the moment on 13,14,15. What about 12? In
>>>>> general, where can I view successful build logs?
>>>>>
>>>>> The reason I ask is to isolate an apparent binary library api
>>>>> incompatibility change between two apple gcc versions (e.g. the one on
>>>>> 12 and the one on 13). The library in question is built to dynamically
>>>>> resolve undefined symbols in the running executable, which (to my
>>>>> understanding) works fine at least on 10,11, and 12. I suspect there
>>>>> were some 'namespace' changes which affect the search algorithm for
>>>>> undefined symbols, and this could be addressed by adding an appropriate
>>>>> linker flag to the creation rule of libboot.so.
>>>>>
>>>>> Thankfully, even if this fails, it is only a nuisance. I'm working a
>>>>> little on a cygwin port, and there such libraries are not supported at
>>>>> all. We can easily compile in this library at the cost of wasted space
>>>>> in the final executable if need be.
>>>>>
>>>>> Then the general question -- I assume this is all testing the installed
>>>>> apple gcc/clang/llvm. What about using the macports gcc? We should
>>>>> support both, but the latter would seem to be closer to the widely
>>>>> tested Linux gcc as a start.
>>>>>
>>>>> For any interested, this latest release has made a start on a systematic
>>>>> approach to bootstrapping common lisp. A long time ago there was a
>>>>> thought to write everything in C, but this is very cumbersome and
>>>>> limited technically. Then a '.d' file syntax was invented as a crude
>>>>> bridge, etc. Now we have what will be a shrinking C core implementing
>>>>> a interpreter, maybe eventually just funcall/apply, eval, and
>>>>> macroexpand. We load everything else in .lsp and interpret the
>>>>> compilation to safety level3. Then we use that compiler to compile to
>>>>> (default) safety level 0, etc. This is akin to the staged process
>>>>> followed by gcc. What we have now is very preliminary in this regard.
>>>>> It does have the 'dogfood' detection benefits of exercising everything
>>>>> at all safety levels and catching errors quickly. There is some
>>>>> assurance in a successful build that the code is at least logically
>>>>> correct.
>>>>>
>>>>> libboot.so is code that I need to run the early interpreter which itself
>>>>> cannot (yet) be interpreted, but which is defined later elsewhere and
>>>>> does not need to appear in the final image. Hence a shared library
>>>>> opened by dlopen only in the raw image and pre image stages.
>>>>>
>>>>> In any case, the answers to the above questions will help us figure out
>>>>> how to handle this.
>>>>>
>>>>> Take care,
>>>>>
>>>>> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes:
>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> Finally I have a "working" Portfile (in attach) for gcl27, tested on
>>>>>> MacPorts'
>>>>>> GitHub CI workflow, including macOS 13 x86, macOS 14 arm64 and macOS 15
>>>>>> arm64.
>>>>>>
>>>>>> On macOS 13 x86, you can find the building logs from the following link
>>>>>> (I put a
>>>>>> copy in attach in case the link is no more available in the future).
>>>>>>
>>>>>> https://github.com/binghe/macports-ports/actions/runs/14638869916/job/41076302619
>>>>>>
>>>>>> The building log shows that "unixport/saved_pre_gcl" has been built
>>>>>> successfully
>>>>>> but then it follows a segmentation violation:
>>>>>>
>>>>>> echo "(system:save-system \"unixport/gcl0\")" | cat unixport/cinit.lisp
>>>>>> - |
>>>>>> unixport/saved_pre_gcl
>>>>>>
>>>>>> dlopen(/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_lang_gcl27/gcl27/work/gcl-2.7.1/unixport/libboot.so,
>>>>>> 0x0009): symbol not found in flat namespace '_Cnil_body'
>>>>>> dlsym(0x0, gcl_init_boot): invalid handle
>>>>>> Segmentation violation: c stack ok:signalling errorSegmentation
>>>>>> violation: c
>>>>>> stack ok:signalling error
>>>>>> Unrecoverable error: Segmentation violation..
>>>>>> /bin/sh: line 1: 12984 Done echo
>>>>>> "(system:save-system
>>>>>> \"unixport/gcl0\")"
>>>>>> 12985 | cat unixport/cinit.lisp -
>>>>>> 12986 Abort trap: 6 | unixport/saved_pre_gcl
>>>>>> make[1]: *** [unixport/gcl0] Error 134
>>>>>>
>>>>>> Is there anything we can learn just by watch this log?
>>>>>>
>>>>>> --Chun
>>>>>>
>>>>>> On 24/04/25 08:02, Camm Maguire wrote:
>>>>>>> Greetings! Just a quick note that we've recently verified that GCL self
>>>>>>> builds, builds ACL2, and runs its regression without error (16 parallel
>>>>>>> processes taking several hours), using the apple supplied gcc. When we
>>>>>>> get a macports package, I imagine we will use the macports gcc, but I
>>>>>>> expect the results to be the same.
>>>>>>>
>>>>>>> Take care,
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
signature.asc
Description: OpenPGP digital signature
