Re: 2.7.1 on Mac x86

[Camm Maguire]

Greetings, and thanks again for your notes and work!

"Chun Tian (binghe)" <binghe.lisp@gmail.com> writes:

> Greetings,
>
> Note that this type conversion issue is totally on compiler level (and not at
> linker level), therefore I have switched to macports gcc 13, and it turns out
> that now GCL 2.7 can be build, even without your this patch, on *most* x86
> versions of macOS (I have tried versions 10.13, 10.14, 10.15, 11, 12, 13, 14 
> and
> 15, and I believe even 10.9 should work.)

Wonderful!  But I understood from your message on 4/27 that with
--disable-libboot, gcc-14 also works on x86, no?  Can you please
summarize any remaining x86 breakage combos using --disable-libboot?

>
> I'm pushing MacPorts maintainer to accept my current port definitions. The
> "progress" tracking page you asked in the other email, can be provided by
> MacPorts, but only after they accept my initial port file for gcl27. For gcl 
> 2.6
> it is here [1].
>
> [1] https://ports.macports.org/port/gcl/details/

Thanks to much, I understand now!

BTW, I've downloaded arm64-macosx-83e426c5-3.log, and it does not appear
to report the gcc version anywhere.  I assume we could arrange to output
that in configure if need be.

>
> For the remaining issues on ARM64 Mac, I'm sure the situation will be much
> better once you can access to my M4 Mac mini computer through SSH (with 
> support
> of using LLDB remotely) and can freely try different solutions.
>

Great!

Take care,

> --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.lisp@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.lisp@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.lisp@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,
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> 
>

-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah