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
