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
