Greetings! I'm glad to report that, with this new --disable-libboot option now I have obtained a successful build of gcl27 on macOS 13 x86_64. Great job you have done! Thanks! Below is the link containing the full building log (this time I don't attach it because its size is over 2MB):
https://github.com/binghe/macports-ports/actions/runs/14697859343 I hope you can make a new Debian sid package update soon, so that I can include the official patch (Version_2_7_2pre3) as part of the port definition. I will confirm the building status on other Intel macOS versions and report back soon. Let's hope it just work out-of-box on macOS 15, for those who still has Intel Mac computers. P.S. On macOS 10.15 Catalina, now I can install "gcl" and "gcl27" packages together, after renaming some files same the way as the Debian package "gcl27" (therefore the entry execution for gcl27 is now /opt/local/bin/gcl27) --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
