Greetings, and please excuse the delayed reply! I have been concentrating on fixing a race condition bug in the build, which I will write about separately.
"Chun Tian (binghe)" <binghe.l...@gmail.com> writes: > Greetings, > > That's very interesting (that ARM64 macOS is more optimized in function calls > of > variable arguments), and it seems that GCL's source code becomes more > standard-compliant with these fixes. > > But I wonder if this issue can be avoided (for now) if we use MacPorts GCC 13 > (or 14) to compile GCL on ARM64 macOS? Good suggestion -- I hope to return to the mac arm port shortly, and will look at this. > > On the other hand, MacPorts maintainers do not like that I included GCL > pre-release patches (~3000 lines since 2.7.1 release) as part of the port > definitions. Is it possible that you can make a new (intermediate) release > before the ARM64 macOS support is done? This is surely possible, but we had previously discussed supporting mac arm as a release goal for 2.7.2. Do you feel it better to push that off now? My understanding from your previous comments was essentially that the entire mac user base was going arm, or already had. > It would be even better if you can port the "libboot" patch and other > necessary changes to GCL 2.6 branch. There is no libboot in 2.6.x. Are there any other mac x86 issues with currentl gcl 2.6.15pre? > I think it's definitely not needed to support ARM64 macOS for GCL > 2.6.x, but it would be nice if GCL 2.6.15 (if it's the last 2.6.x > release) can run on macOS 15. Agreed. I am unaware of any issues blocking same, so if there are any and you can summarize, that would be most helpful! Take care, > > --Chun > > On 12/05/25 04:51, Camm Maguire wrote: >> Greetings! >> >> This link spells out what is going on uniquely on this machine: >> >> https://cpufun.substack.com/p/what-about- >> >> Briefly, the regular arguments and the elipsis if any needs to be in the >> right location in the prototype for function calls through pointers to >> succeed. One can call a regular function through a variadic pointer if >> the prototype has at lease enough regular arguments in its prototype to >> match the fixed arguments of the function. >> >> The basic changes needed in gcl are >> >> 1) h/apply_n.h -- our 64 entry switch table for function calls needs >> expanding to ~ 64^2 entries at least in the naive approach. About 2Mb >> of code for this table(!) >> >> 2) The function prototypes in C files produced by the compiler need to >> be rewritten. Thankfully one accurate prototype can be used here with >> the fast-link mechanism falling back to the apply_n.h table in case of >> signature incompatibilities. >> >> I'm sure there is a better way -- no doubt there are many interpreters >> already ported to Mac/arm, and they all have some sort of generic >> funcall mechanism. >> >> Take care, >> >> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes: >> >>> Greetings, >>> >>> On 01/05/25 12:54, Chun Tian (binghe) wrote: >>>> Greetings, >>>> >>>> I found another (minor) issue when building GCL in macOS. The system >>>> command >>>> "mktemp" of macOS doesn't support "-p" option (in "xbin/mktmp"). How to >>>> rewrite >>>> this script by using, e.g., "-t" instead: >>>> >>>> -p DIR, --tmpdir[=DIR] >>>> interpret TEMPLATE relative to DIR; if DIR is not specified, >>>> use >>>> $TMPDIR if set, else /tmp. With this option, TEMPLATE >>>> must not >>>> be an absolute name; unlike with -t, TEMPLATE may >>>> contain >>>> slashes, but mktemp creates only the final component >>>> >>>> -t interpret TEMPLATE as a single file name component, relative >>>> to a >>>> directory: $TMPDIR, if set; else the directory specified >>>> via -p; >>>> else /tmp [deprecated] >>>> >>> >>> I just figured out that I can install MacPorts' "coreutils" package, which >>> provides the GNU version of "mktemp". >>> >>> Furthermore, by using MacPorts' "legacy-support" package, the missing >>> "readlinkat" system call will be provided. (I will need to learn how to use >>> this >>> package.) >>> >>> Therefore no more blocking issues on supporting GCL 2.7 in earlier macOS >>> versions. You don't need to do anything here. >>> >>> In general, I think it's totally reasonable for GCL to depend on some other >>> GNU >>> tooling packages (on macOS), including GCC (if necessary). >>> >>> --Chun >>> >> > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
