Greetings!
"Chun Tian (binghe)" <[email protected]> writes:
> Hi,
>
> I confirm the following patch (according to your hints) makes GCL 2.7
> successfully built on macOS 15 x86 using Apple clang compiler:
>
Great! Which clang version is this?
> --- 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).
>
Agreed, gcl should build with both. But the above implies there remains
some x86 combos which don't work. If you could summarize these I'd be
most appreciative!
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)" <[email protected]> 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)" <[email protected]> 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)" <[email protected]> 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 [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
