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)" <[email protected]> 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 [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
