Re: 2.7.1 on Mac x86

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FFWaSPSBcpVvx644dEhWYVqIOzLo2uxov
Content-Type: multipart/mixed; boundary="rdVqgOZSgWsjw5toVv6gb0znTGflncAsi";
 protected-headers="v1"
From: "Chun Tian (binghe)" <[email protected]>
To: Camm Maguire <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Subject: Re: 2.7.1 on Mac x86
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>

--rdVqgOZSgWsjw5toVv6gb0znTGflncAsi
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I confirm the following patch (according to your hints) makes GCL 2.7
successfully built on macOS 15 x86 using Apple clang compiler:

--- a/gcl/h/386-macosx.h
+++ b/gcl/h/386-macosx.h
@@ -132,7 +132,7 @@ if (realpath (buf, fub) =3D=3D 0) {                  =
           \
 #define UC(a_) ((ucontext_t *)a_)
 #define SF(a_) ((siginfo_t *)a_)

-#define FPE_CODE(i_,v_) make_fixnum(FFN(fSfpe_code)(*(fixnum
*)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mx=
csr))
+#define FPE_CODE(i_,v_) make_fixnum((fixnum)FFN(fSfpe_code)(*(fixnum
*)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mx=
csr))
 #define FPE_ADDR(i_,v_) make_fixnum(UC(v_)->uc_mcontext->__fs.__fpu_fop =
?
UC(v_)->uc_mcontext->__fs.__fpu_ip : (fixnum)SF(i_)->si_addr)
 #define FPE_CTXT(v_) list(3,make_fixnum((fixnum)&UC(v_)->uc_mcontext->__=
ss), \

make_fixnum((fixnum)&UC(v_)->uc_mcontext->__fs.__fpu_stmm0), \

* * *

Having GCL 2.7 buildable by default Apple compiler will ease the users wh=
o wants
to build GCL from sources with customized options. For the MacPorts packa=
ge, I
still think MacPorts GCC 13 is a good option, because so far I can use it=
 to
build GCL even in macOS 10.10 (perhaps 10.9 also works).

--Chun

On 01/05/25 01:08, Camm Maguire wrote:
> Greetings!
>=20
> Yes, please place (fixnum) before FFN(fSfpe_code... as in h/linux.h:
>=20
> #define FPE_CODE(i_,v_) make_fixnum((fixnum)FFN(fSfpe_code)(*(fixnum *)=
&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu_mxcs=
r))
>=20
> and let me know if it works, and I'll commit.
>=20
> All these FPE_ macros will have to be adjusted for arm, or disabled.
>=20
> Question -- are apple clang 14/16 identical to those found in Debian?
>=20
> Regarding the arm build, both apple clang 14 and homebrew gcc 14 are
> available on the mac mini arm I am investigating.  There seems to be a
> fundamental difference between arm and x86 versions of this compiler.
> Ideally I would like to make them the same with some missing compiler
> flag.  But as it stands, both 'cc' version 14 will not process correctl=
y
> calls through a generic function pointer, e.g. (object(*)()), even when=

> std=3Dgnu17 is set.  At a minimum, variadic functions require a prototy=
pe
> (object(*)(object,...)).  Calls through the first(second) to targets of=

> the second(first) type both fail.
>=20
> This paradigm is used extensively in the code.  It can be addressed, bu=
t
> not trivially.  I am almost at the point where I can load the lsp sourc=
e
> files and save saved_pre_gcl.  There is of course no debugger, so print=
f
> debugging only....  If you know of any way these compilers can be
> instructed to use the older C paradigm for now, please let me know.
>=20
> This issue, together with the arm warnings you sent earlier, all fall
> under the topic 'C23', referring to the new standardization of the
> language.  I have created a branch c23, and pushed edits clearing your
> compiler warnings to it.  This is only a partial work, as GCL produced =
C
> code also needs addressing.  Eventually all these function pointers nee=
d
> the correct prototypes.  But it should be possible for now to compile
> under the older paradigm still with some flag, and I think it would be
> prudent for us to get that working first, and then c23 later.
>=20
> Take care,
>=20
> "Chun Tian (binghe)" <[email protected]> writes:
>=20
>> Unfortunately the building of latest gcl27 (master) on macOS 14 and ma=
cOS 15 are
>> both failed at the following compilation error: (it looks like an easy=
 type
>> conversion issue?)
>>
>> :info:build 	/usr/bin/clang -DHAVE_CONFIG_H -I. -I./h  -I h -I
>> /usr/include/tirpc -I/opt/local/include
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk  -pipe =
-Os
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch x=
86_64
>> -fsigned-char -pipe -fcommon -fno-builtin-malloc -fno-builtin-free -fn=
o-PIE
>> -fno-pie -fno-PIC -fno-pic -std=3Dgnu17 -Wall -Wno-builtin-requires-he=
ader
>> -Wno-empty-body -Wno-self-assign -Wno-unused-but-set-variable
>> -D_FILE_OFFSET_BITS=3D64 -D_TIME_BITS=3D64 -fbracket-depth=3D512
>> -Wno-incomplete-setjmp-declaration -m64   -I/opt/local/include
>> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -O3
>> -fomit-frame-pointer -I o  -MT o/usig.o -MD -MP -MF $depbase.Tpo -c -o=
 o/usig.o
>> o/usig.c &&\
>> :info:build 	mv -f $depbase.Tpo $depbase.Po
>> :info:build o/usig.c:237:36: error: incompatible pointer to integer co=
nversion
>> initializing 'fixnum' (aka 'long') with an expression of type 'object'=
 (aka
>> 'union lispunion *') [-Wint-conversion]
>> :info:build   237 |
>> ifuncall3(sSfloating_point_error,FPE_CODE(i,v),FPE_ADDR(i,v),FPE_CTXT(=
v));
>> :info:build       |                                    ^~~~~~~~~~~~~
>> :info:build ./h/config.h:135:25: note: expanded from macro 'FPE_CODE'
>> :info:build   135 | #define FPE_CODE(i_,v_) make_fixnum(FFN(fSfpe_code=
)(*(fixnum
>> *)&UC(v_)->uc_mcontext->__fs.__fpu_fsw,UC(v_)->uc_mcontext->__fs.__fpu=
_mxcsr))
>> :info:build       |
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> :info:build ./h/../h/fixnum.h:36:44: note: expanded from macro 'make_f=
ixnum'
>> :info:build    36 | #define make_fixnum(a_)  ({register fixnum _q1=3D(=
a_);register
>> object _q3;\
>> :info:build       |                                            ^   ~~~=
~
>> :info:build 1 error generated.
>> :info:build make[1]: *** [o/usig.o] Error 1
>> :info:build make[1]: Leaving directory
>> `/opt/local/var/macports/build/_Users_binghe_Lisp_macports-gcl_lang_gc=
l27/gcl27/work/gcl-2.7.1'
>>
>> Note that on macOS 13 the default C compiler is Apple clang 14.0.0 (wh=
ich is
>> successfully in building GCL 2.7), while on both macOS 14 and 15 the c=
ompiler is
>> Apple clang 16.0.0. I believe the above error will show up too if the =
building
>> process on ARM64 macOS can reach this far.
>>
>> --Chun
>>
>> On 28/04/25 06:09, Camm Maguire wrote:
>>> Greetings!  I've pushed a --disable-libboot configure option to maste=
r
>>> you might want to try out.  Still looking for the right incantation t=
o
>>> make it work as it does elsewhere, but this requires deep knowledge f=
or
>>> the mac.
>>>
>>> Take care,
>>>
>>> "Chun Tian (binghe)" <[email protected]> writes:
>>>
>>>> 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 errorSegme=
ntation
>>>> 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.li=
sp -
>>>> :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 GC=
C 13, but
>>>> the error outputs are identical. Therefore I think the above issue w=
ith
>>>> 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 'po=
int
>>>>> of the spear' with macports!
>>>>>
>>>>> Please enlighten me a little regarding the pull request process.  M=
y
>>>>> crude understanding is that we build fine on macos 10 (catalina), y=
ou 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 dynamic=
ally
>>>>> resolve undefined symbols in the running executable, which (to my
>>>>> understanding) works fine at least on 10,11, and 12.  I suspect the=
re
>>>>> were some 'namespace' changes which affect the search algorithm for=

>>>>> undefined symbols, and this could be addressed by adding an appropr=
iate
>>>>> 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 s=
pace
>>>>> in the final executable if need be.
>>>>>
>>>>> Then the general question -- I assume this is all testing the insta=
lled
>>>>> apple gcc/clang/llvm.  What about using the macports gcc?  We shoul=
d
>>>>> 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 syste=
matic
>>>>> 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 cru=
de
>>>>> bridge, etc.  Now we have what will be a shrinking C core implement=
ing
>>>>> 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 rega=
rd.
>>>>> It does have the 'dogfood' detection benefits of exercising everyth=
ing
>>>>> at all safety levels and catching errors quickly.  There is some
>>>>> assurance in a successful build that the code is at least logically=

>>>>> correct. =20
>>>>>
>>>>> libboot.so is code that I need to run the early interpreter which i=
tself
>>>>> cannot (yet) be interpreted, but which is defined later elsewhere a=
nd
>>>>> 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)" <[email protected]> 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 mac=
OS 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 buil=
t successfully
>>>>>> but then it follows a segmentation violation:
>>>>>>
>>>>>> echo "(system:save-system \"unixport/gcl0\")" | cat unixport/cinit=
=2Elisp - |
>>>>>> unixport/saved_pre_gcl
>>>>>>
>>>>>> dlopen(/opt/local/var/macports/build/_Users_runner_work_macports-p=
orts_macports-ports_ports_lang_gcl27/gcl27/work/gcl-2.7.1/unixport/libboo=
t.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:sav=
e-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 G=
CL self
>>>>>>> builds, builds ACL2, and runs its regression without error (16 pa=
rallel
>>>>>>> processes taking several hours), using the apple supplied gcc.  W=
hen we
>>>>>>> get a macports package, I imagine we will use the macports gcc, b=
ut I
>>>>>>> expect the results to be the same.
>>>>>>>
>>>>>>> Take care,
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>=20


--rdVqgOZSgWsjw5toVv6gb0znTGflncAsi--

--FFWaSPSBcpVvx644dEhWYVqIOzLo2uxov
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEES+aY+4laoC0TwmVKFUkg2jrYR8gFAmgS49sACgkQFUkg2jrY
R8g7UhAAkFcptLNTIxtNnj/FQPsy23qEs6fRyyf9orwIff39/3cpWAEQMD+M9xiV
C0+hJJ7LpD/Vyq6AspxB7hZtiM7BJ40A2YurIS5Akf/tFNhL16Gd1rNAt5PpRBqs
EilhYXFTrXrrIMdrI5I2AQ3T+drwbaH4KUSp54/1JVxQ4wQCGgWpnutTeeEq5H9k
ZlRzqGzhUzM24KZNnMmerv35RVqm3s4jjd94jRyQXamE/RlcHkDzVSTS4paoRIkO
StJ9ydXJq6HkPQ/aBPNpQARIVLbtUF8ZxxHEBdNLTkd/TJmXS+yNkiD8BgUPp0z+
WnDBESyrH4InRz6EgRmf8u/7YNMeydSTktu1GExF06HpzR/1Sv10ZYNAvMz0NWj4
PVLSPTbGjFPuFNTxQgQv1ZOZN+zke0WbEd9+QLRCzL5KndE0THQ/e6AX574d+1Yb
/2EyoT7EiTIjHlGjuVAIO1JCPv1sPpL0lK7xwnamyQ477PJES9WyhcI3hk/MmcBC
VGohs/3gPoL44zSUIbg4e6RIe0ikHqGZSWVsjzJ3w1OzWqHDCKkmkHpVOt5I66kz
59WC2pxg6JJ7koErs5ye1D9VWDQr9z5XDX9yj7eMUZ6HBMhRtnYDYzfm6f3jAUL8
Ga170xrdXVi9zRCnBn587oqaPs7tCG8lcfU0pTfwMicMhzRGDHc=
=Bj1a
-----END PGP SIGNATURE-----

--FFWaSPSBcpVvx644dEhWYVqIOzLo2uxov--