Greetings, and thank you so much! More detail later, but if you could please quickly tell me if your test included commit:
d642ccb68 * remove AC_FUNC_ALLOCA I believe that will resolve your compilation difficulties. If you could let me know quickly either way I would be most appreciative! Take care, "Chun Tian (binghe)" <binghe.l...@gmail.com> writes: > Greetings, > > Please find attached files (two new C headers and the execution log for > configure and make). Note that I have used the name "arm64" instead of > "aarch64" > for the architecture name, because that's how macOS's system headers name it. > Note that I also replaced some macros (FPE_INIT related) by copying related > non-x86 code from h/linux.h. > > Unfortunately I cannot reach that far - there are C compilation errors when > building saved_pre_gcl. There are at least the following issues: > > 1. macOS's typedef of "size_t" (= __darwin_size_t) is incompatible with > "#define > size_t unsigned int" generated in /h/gclincl.h > > 2. undeclared identifiers (such as 'RA_unsigned') in h/gmp_wrappers.h. I'm not > sure which GMP library I'm actually using (MacPorts' GMP is not used for sure) > > 3. 'h/new_decl.h' file not found (or not generated?) > > --Chun > > On 18/04/25 23:41, Camm Maguire wrote: >> Greetings! Great, something I can understand! >> >> I am assuming per our previous conversations that there is no virtualbox >> image possible here. >> >> Do you have access to such a machine? Would you be willing to engage in >> a short dialog constructing this file? It should not be too hard. >> >> If so, the first step is to copy the 386-macosx.h file to >> aarch64-macosx.h, and replace >> >> #include <mach-o/x86_64/reloc.h> >> #define RELOC_H "mach64_i386_reloc.h" >> >> with >> >> #include <mach-o/aarch64/reloc.h> >> #define RELOC_H "mach64_aarch64_reloc.h" >> >> then make an empty file h/mach64_aarch64_reloc.h. >> >> Then configure with --enable-machine=aarch64-macosx >> >> and >> >> make unixport/saved_pre_gcl. >> >> Make two small .lsp files: >> >> ============================================================================= >> /tmp/f.l >> ============================================================================= >> (defun foo nil nil) >> ============================================================================= >> >> ============================================================================= >> /tmp/g.l >> ============================================================================= >> (defun bar nil (unwind-protect nil nil)) >> ============================================================================= >> >> Execute unixport/saved_pre_gcl and >> >>> (compile-file "/tmp/f.l") >>> (compile-file "/tmp/g.l") >>> (si::bye) >> >> then send me >> >> objdump -d /tmp/f.o >> objdump -r /tmp/f.o >> >> objdump -d /tmp/g.o >> objdump -r /tmp/g.o >> >> Take care, >> >> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes: >> >>> Greetings, >>> >>> On 18/04/25 00:26, Camm Maguire wrote: >>>> Greetings! >>>> >>>> "Chun Tian (binghe)" <binghe.l...@gmail.com> writes: >>>> >>>>> On 12/04/25 21:14, Camm Maguire wrote: >>>> >>>>>>> Do you have release plans for GCL 2.6.15? >>>>>> >>>>> >>>>> At this moment I'm not sure 2.7 is really better in every respect. I saw >>>>> you >>>>> were trying to build Debian "axiom" package by GCL 2.7 but it seems that >>>>> currently the Debian package is still based on GCL 2.6 (I don't have >>>>> Debian sid >>>>> environment, only a Debian testing.) >>>>> >>>>> If you can make a 2.6.15 release (and consider it's the last 2.6.x >>>>> release), one >>>>> immediate good thing is that I can send a small PR to MacPorts to update >>>>> existing "gcl" package, such that it will work on more macOS versions >>>>> (more than >>>>> what 2.6.14 can support). And I think it's good to have Axiom (ACL2, >>>>> Maxima, >>>>> etc.) to support both GCL 2.6.15 and 2.7.1, and then people can compare >>>>> on the >>>>> performance of these software under different GCL versions, to confirm if >>>>> GCL >>>>> 2.7 is really better in every respect. >>>> >>>> OK, you have persuaded me. But I think it would be good to get the mac >>>> arm build working before the next release. 2.6.13 only lasted one >>>> month, so perhaps we could try a cleanup only 2.6.15 and 2.7.2 in this >>>> time frame, and then move on to other items. Can you please point me to >>>> a build log showing the arm failure? I've explored the macports site >>>> and cannot find it. >>>> >>> The immediate issues when trying to build GCL (2.6 and 2.7) in ARM64 macOS, >>> is >>> that the "configuration" script cannot pass. I think the key issue is that >>> no >>> such configuration "aarch64 + macosx" exists in h/*. For GCL 2.7, using >>> i386-macosx as a workaround doesn't work (of course). (I wanted to learn >>> the >>> way of aarch64-linux but then found h/linux.h is mostly related to ELF >>> format >>> while macOS uses Mach-O.) >>> >>> In attach you can find 3 logs as the outputs of configuration scripts. I >>> think >>> the first step is to figure out a reasonable "aarch64-macosx.h". >>> >>> --Chun >>> >>> >>> >>> >> > > > > -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
