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
