Greetings, and thanks again for your notes and work! "Chun Tian (binghe)" <binghe.l...@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.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, >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
