Re: 2.7.1 on Mac x86

[Camm Maguire]

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