Re: 2.7.1 on Mac x86

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wgrU7FIN10h2ayEIqlOvcWn8RkRmq5ufC
Content-Type: multipart/mixed; boundary="UI0XEX0JAYnkWGebJQfGNAsNc7kk0NN2L";
 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]>

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

Greetings,

I found another (minor) issue when building GCL in macOS. The system comm=
and
"mktemp" of macOS doesn't support "-p" option (in "xbin/mktmp"). How to r=
ewrite
this script by using, e.g., "-t" instead:

      -p DIR, --tmpdir[=3DDIR]
              interpret TEMPLATE relative to DIR; if DIR is not specified=
,  use
              $TMPDIR  if  set, else /tmp.  With this option, TEMPLATE mu=
st not
              be an  absolute  name;  unlike  with  -t,  TEMPLATE  may  c=
ontain
              slashes, but mktemp creates only the final component

       -t     interpret TEMPLATE as a single file name component, relativ=
e to a
              directory:  $TMPDIR, if set; else the directory specified v=
ia -p;
              else /tmp [deprecated]

--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


--UI0XEX0JAYnkWGebJQfGNAsNc7kk0NN2L--

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

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

iQIzBAEBCAAdFiEES+aY+4laoC0TwmVKFUkg2jrYR8gFAmgS4lAACgkQFUkg2jrY
R8hJ8A/+J5aBxwfCwQXwCll1AHgZBtf4KO8iPVMSPx/pUlI9BsJDKLi9lK+r8lQJ
jGHHyeDRlAOnDI44BRgPMLDkCvTWxrBfoLh77M7NReSiXV6REsvsO+IieF2ysQSr
PkXS8N/bCnqr3rwM+J/1GQNPCUouzHNyPDF3gyCjGCvZ2kp8SP2ftUHwxC/yV2Xl
8kvYqaUnmgPBrgz8BhVCWdQVEUYX6UoEO5SIQP+QnWqleuoc+XUlMlwCP3Ta+7BD
omEGTWKWt3I1bNKj/i6oUsmGkWmjq3BAJTNsVMttRTBODpHMvop7ApU2+gWGpTGv
+7wI6U6bKuY5ctoWgK/vW2TX8gQ4auk5XzTxbqhJTxzgxwc5URWUsgMQbx2WBv0d
GTCP3Sqq/d7I5XDBoFlezQ7mC5OyantcQc90l1EdppJ4tGce17bRbuWOrE/AuJxD
QhbUZRxd+OvcczsyOQFnlXGS1eCSPlR0eTnPOnVU96i7LWFj34QxknOZwKLh10jv
gwBEB9KZEN8o92g0SGVWm9SeCHoDgMzIkzjj5OTIRpgRH++DOmS2GTHBfIocGcMF
q5CPzfNHom4BT9A6vxNzvD7oJ9nKZYYxlRL3INUaBAZh6rNIVSabrZxpkZKRLd9Y
endr6hQoU/B+JMQonZTmWwGRtVrS+zor4c3eJqeHreA9T0rhSI0=
=b6Of
-----END PGP SIGNATURE-----

--wgrU7FIN10h2ayEIqlOvcWn8RkRmq5ufC--