Re: macos status

Greetings, No, I haven't involved with macports anymore. On Mon, 24 Feb 2025 17:09:46 +0100, Camm Maguire wrote: > > Greetings! Its been some time since we've checked in -- are you both > still involved with macports? > > I have a small commit forthcoming to restore the master build on my > C

Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

On Wed, 21 Feb 2024 00:45:52 +0100, Camm Maguire wrote: > > x86_64 please. Did not know macos had arm64, but we can deal with that > later > For couple of yers, and I expect that macOS 14 is the last one which supports x86_64. But we will see it in a few month. -- wbr, Kirill

Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

On Tue, 20 Feb 2024 20:11:31 +0100, Camm Maguire wrote: > > Thanks so much! No rush at all. SSH key sent in separate email. > arm64 or x86_64? -- wbr, Kirill

Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

On Tue, 20 Feb 2024 01:19:03 +0100, Camm Maguire wrote: > > I do think the Sonoma access is probably the most efficient way to go > from here. > I do have mac mini, both amd64 and x86_64 which just stay pluged and I haven't using it. I can upgrade it to Sonoma and grand you access, but not rigth

Re: macOS status

On Fri, 02 Feb 2024 20:28:06 +0100, Chun Tian (binghe) wrote: > > If you only have the command line tools, I think the Apple clang version > can uniquely identify it. In my Catalina box it's 12.0.0 and in Sonoma > it's 15.0.0: It can be also discovered via sw_vers -productVersion > > Actually I

Re: lldb and interrupted system call

Greetings, On Fri, 02 Feb 2024 16:37:45 +0100, Camm Maguire wrote: > > Greetings! When running under lldb, running any subprocess via > posix_spawn fails at waitpid with errno set to 'interrupted system > call'. I suppose I could try blocking things, but suggestions? > A lot of reason that may

Re: macOS status

Greeting, On Fri, 02 Feb 2024 14:22:02 +0100, Camm Maguire wrote: > > I get: > > xcode-select: error: tool 'xcodebuild' requiers Xcode, but active > developer directory '/Library/Developer/CommandLineTools' is a command > line tools instance. > To use xcodebuild You need to install Xcode. To do

Re: macOS status

On Thu, 01 Feb 2024 23:45:36 +0100, Chun Tian (binghe) wrote: > > And I don't think gprof is available in the MacPorts-installed GCC. > Perhaps that's why Kirill used --disable-gprof when calling "./configure". > macOS is very Clang oriented and building anything with GCC is tricky. Do not forge

Re: macOS status

Greetings, On Thu, 01 Feb 2024 00:40:29 +0100, Chun Tian (binghe) wrote: > > Great, thanks! Let me reproduce your success on macOS 12 first. (I'm not > very useful here except that I can be a good manual tester.) > I'd like to point that current master doesn't build. I had build it last time i

Re: macOS status

On Thu, 01 Feb 2024 00:00:28 +0100, Chun Tian (binghe) wrote: > > I think for Camm the only purposes of using MacPorts is to easily get > GCC and various open source tools installed in his Catalina box. For > examples, after a successful installation, a simple command like "sudo > port install gcc

Re: macOS status

On Wed, 31 Jan 2024 23:09:32 +0100, Camm Maguire wrote: > > Greetings! Also, is there anything I can do to shorten the > pathnames/filenames in the macports builds? > I don't know any way to do it -- wbr, Kirill

Re: macOS status

On Wed, 31 Jan 2024 22:55:43 +0100, Camm Maguire wrote: > > Greetings, and thanks for these instructions. Making progress here, but > > Kirill A. Korinsky writes: > > > The simplest way to update it is: > > 1. Update git commit > > I have no command 'Upd

Re: macOS status

Greetings, On Wed, 31 Jan 2024 17:10:32 +0100, Camm Maguire wrote: > > This alone should be reason enough to abandon Apple and its products. > We are building an edifice on a foundation of sand which at any moment > can be pulled from under our feet by an external commercial entity with > its own

Re: macOS status

On Wed, 31 Jan 2024 17:25:40 +0100, Camm Maguire wrote: > > Greetings! I've found the catalina pkg installer for macports. Is > everything installed under /opt? Are all existing programs, perhaps once > installed via 'xcode', unaffected? Any PATH setup requirements? > Yes, everything is inst

Re: gmp4

On Tue, 30 Jan 2024 20:25:11 +0100, Camm Maguire wrote: > > Greetings! One other thing I would like to do is eliminate the old > convenience copy of gmp for use in cases where the external library is > not present. If memory serves this was mostly used on macosx. Is this > directory (gmp4) now o

Re: macOS status

Greetings, On Tue, 30 Jan 2024 17:28:11 +0100, Camm Maguire wrote: > > I have an old mac virtualbox which I never use except at the last point > in gcl releases. Nonetheless I have fired it up, and run into the > problem that sed cannot put newlines into the replacement text. You > guys are sure

Re: macOS status

Greetings, On Tue, 30 Jan 2024 16:17:43 +0100, Camm Maguire wrote: > > Greetings! Unexpected. At this point please do > > cd unixport > make raw_gcl_gcl > gdb raw_pcl_gcl > (gdb) r ./ (gdb) bt > You'll love it! sh-3.2$ make raw_pcl_gcl ls: gcl_recompile?*.o: No such file or directory gr

Re: macOS status

On Mon, 29 Jan 2024 23:48:16 +0100, Chun Tian (binghe) wrote: > > I think it's OK to ignore macOS versions where readlinkat() is not > available, because on those old platforms GCL 2.6.12 at least works. > I totally agree with you! Also, keep in mind that readlinkat() were reimplemented to lega

Re: macOS status

On Mon, 29 Jan 2024 15:51:57 +0100, Camm Maguire wrote: > > Greetings! Found it, thanks so much! You should be good to go now on > master. Please let me know if problems persist. > The old one has gone. Anyway, after couple of hours of building (like 3) it fails as: SYSTEM>Initializing gcl_s.

Re: macOS status

On Mon, 29 Jan 2024 14:20:27 +0100, Camm Maguire wrote: > > Greetings! OK then please repeat the last instructions, inserting the > following before (load "boot.lisp") > > >(trace si::readlinkat) > Here it is: >(si::use-fast-links nil) NIL >(trace si::readlinkat) (SYSTEM:READLINKAT)

Re: macOS status

On Mon, 29 Jan 2024 04:37:55 +0100, Camm Maguire wrote: > > But configure did not detect it in your problem build? > As far as I see it did: configure:9002: checking for readlinkat configure:9002: /usr/bin/clang -o conftest -pipe -fno-pie -isysroot/Library/Developer/CommandLineTools/SDKs/M

Re: macOS status

On Mon, 29 Jan 2024 00:20:43 +0100, Camm Maguire wrote: > > Greetings, and thanks so much! Its the readlinkat we commented out on > mac -- we need a replacement. Suggestions? > Wired. readlinkat available on modern macOS. I guess it was introduced at 10.10 which was released a decade ago. Se

Re: macOS status

Greetings, On Sun, 28 Jan 2024 16:45:59 +0100, Camm Maguire wrote: > > Greetings, and thanks again so much for your report, and please excuse > the delay. > > I cannot reproduce anywhere else. At the point of failure, please > > cd unixport > ./saved_pre_gcl > >(si::use-fast-links nil) > >(load "

Re: macOS status

Greetings, I see the new commit in GCL: 9fb30a4258010a0c71361da9a450ab32ceab6b38 I just run tests on my laptop and it fails as it was before: Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /var/folders/rq/wqy42lq543z9rwrlj7vf1h4rgn/

Re: macOS status

> On 26. Dec 2023, at 14:03, Camm Maguire wrote: > > Thank you for the link to the 'github/macports/runs' area. I may need a > little tutorial on how to parse the information there. Have there been > three attempts for example? The last one is marked green, but there > appears to be no build l

Re: macOS status

--without-x \ > --disable-xgcl \ > --host=x86_64-apple-darwin \ > --build=x86_64-apple-darwin \ > --target=x86_64-apple-darwin > > make It setups a bit more ENV variables that nessesary but it emulates behaviour of MacPorts. So, I confirm that cra

macOS 13 arm63 with Rosetta

gesA->s.s_dbind=Cnil; > 431 z=alloca(n); >432 snprintf(z,n,"%-*.*s%s",(int)m,(int)m,d,s); > -> 433 if (!(v=dlopen(z,RTLD_LAZY|RTLD_GLOBAL))) >434printf("%s\n",dlerror()); >435 if (!(q=dlsym(v,&quo

Re: posix_spawn

Hello, > On 24. Dec 2023, at 15:17, Camm Maguire wrote: > > "Kirill A. Korinsky" writes: > >> This build was made with local root >> >> It contains patches in addition to posix_spawn which allows to build it on >> macOS 13 arm64 under rosetta

Re: macOS status

cy reset complete on raw_pre_gcl < foo :( -- wbr, Kirill > On 24. Dec 2023, at 21:57, Kirill A. Korinsky wrote: > > as expected > >> --- gcl/o/main.c >> +++ gcl/o/main.c >> @@ -266,8 +266,8 @@ get_gc_environ(void) { >> >>mem_multiple=1.0; >

Re: macOS status

assertion. > The assertion (APPLY (QUOTE ARRAY-IN-BOUNDS-P) ARRAY ...) failed. > > Broken at LET*. Type :H for Help. > 1 (continue) Repeat assertion. > 2 Return to top level. > COMPILER>> > -- wbr, Kirill > On 24. Dec 2023, at 14:46, Kirill A. Korinsky wrote: &

Re: macOS status

as expected > --- gcl/o/main.c > +++ gcl/o/main.c > @@ -266,8 +266,8 @@ get_gc_environ(void) { > >mem_multiple=1.0; >if ((e=getenv("GCL_MEM_MULTIPLE"))) { > -massert(sscanf(e,"%lf",&mem_multiple)==1); > -massert(mem_multiple>=0.0); > +mem_multiple=atof(e); > +massert(mem_m

Re: macOS status

Well, Here a king of chicken and the egg problem: as side effect get_gc_environ setup mem_multiple to 1.0 and after that override it to value which is getting via scanf which trigger the loop. macOS has quite paranoid memory allocation and reset everything to. This means that mem_multiple is 0

Re: posix_spawn

ee(o) && o->sm.sm_fp && > o->sm.sm_fp!=stdin && o->sm.sm_fp!=stdout && o->sm.sm_fp!=stderr) { > + printf("Closing %p, %p %p %p %p %p > %p\n",o->sm.sm_fp,stdin,__stdinp,stdout,__stdoutp,stderr,__stderrp); >

Re: macOS status

> > #ifdef HAVE_MALLOC_ZONE_MEMALIGN > gcl_zone->free_definite_size = (void *) stub_free; > gcl_zone->memalign = (void *) stub_memalign; > #endif > > for (i=0;imalloc_zone_unregister(mzc[i]); > > /* Make our zone the default zone. */ > malloc_z

Re: posix_spawn

Hello, From another hand I've tried to build it with gcl-2.6.14 which requires couple of minutes and simplified version of patch works well. Simplified version of patch: > --- o/main.c > +++ o/main.c > @@ -432,7 +432,7 @@ gcl_cleanup(int gc) { >if (gc) { > > -saving_system=TRUE; > +

Re: macOS status

ill > On 24. Dec 2023, at 15:40, Kirill A. Korinsky wrote: > > Hello, > >> On 24. Dec 2023, at 15:37, Camm Maguire wrote: >> >>> >>> Anyway, failed on build; crash happened inside siLheap_report which is >>> called by the first (init-system

Re: posix_spawn

Hello, > On 24. Dec 2023, at 15:31, Camm Maguire wrote: > > "Kirill A. Korinsky" writes: > >> --- o/main.c >> +++ o/main.c >> @@ -432,7 +432,11 @@ gcl_cleanup(int gc) { >> if (gc) { >> >> saving_system=TRUE; >> + >

Re: macOS status

Hello, > On 24. Dec 2023, at 15:55, Camm Maguire wrote: > > BTW the memory consumption issues should be identical to 2.6. Please > let me know if your mileage varies. 2.6.14 builds on the same machine via same MacPorts with near the same patches without any issue. Much faster and consumes nei

Re: macOS status

Hello, > On 24. Dec 2023, at 15:34, Camm Maguire wrote: > > Please export the environment variable GCL_MEM_MULTIPLE=0.1 or similar > to limit gcl to 1/10 of system memory. There are also ways to do this > at the lisp level in terms of absolute instead of percentage figures. build stuck with o

Re: macOS status

Hello, > On 24. Dec 2023, at 15:37, Camm Maguire wrote: > >> >> Anyway, failed on build; crash happened inside siLheap_report which is >> called by the first (init-system) at ./raw_pre_gcl > > Is this heap report issue the same as your segmentation catcher signal > unblocking issue and limite

Re: Branch Version_2_7_0pre

Hello,On 24. Dec 2023, at 15:13, Camm Maguire <c...@maguirefamily.org> wrote:Greetings!"Kirill A. Korinsky" <kir...@korins.ky> writes:May we ban gprof on macOS completley?I'd rather not as some may use gcc and want to try it out.This is the code that is supposed to

Re: posix_spawn

Hello! > On 24. Dec 2023, at 15:17, Camm Maguire wrote: > > "Kirill A. Korinsky" writes: > >> Thus, additionaly I've added patch below to catch the real place where it >> crashes: >> >> --- o/main.c >> +++ o/main.c >>

Re: macOS status

Two future notes related to macOS 12: 1. GCL-2.6.14 consumes negligible memory, a few hundreds of Mb during its build and work much-much-much faster 2. Outside of MacPorts d01abd92b614b3145cd192be4ae797a8b29a09af with all three patches which I've used at MacPorts fails as: > Warning: GETHASH i

Re: macOS status

yeah, seems this is a root cause: it consumes more than 16Gb of RAM by system's point of view. -- wbr, Kirill signature.asc Description: Message signed with OpenPGP

Re: macOS status

from: > 2023-12-23T21:27:00.8844990Z _gcl_init_system in libgcl.a(sys_gcl.o) > 2023-12-23T21:27:00.8847720Z "_init_gcl_bnum", referenced from: > 2023-12-23T21:27:00.8848790Z _gcl_init_system in libgcl.a(sys_gcl.o) my laptop passes it, but it has a lot (32Gb) ram w

macOS status

I'd like to summarise current macOS status. To make things clear I've pushed changes to GCL port at MacPorts as gcl-devel subport which available here: https://github.com/catap/macports-ports/commit/3614b650ebfb259af2b1320026e00a1bef955fb7

Re: posix_spawn

Sorry, I've missed the local root: 01ed2e0b2f540031171d2258ddccb951735827e7 -- wbr, Kirill > On 23. Dec 2023, at 19:52, Kirill A. Korinsky wrote: > > This build was made with local root > > It contains patches in addition to posix_spawn which allows to build it on &g

Re: posix_spawn

is the right move and it really fixes things. If you think to commit it, please do! -- wbr, Kirill > On 23. Dec 2023, at 01:20, Kirill A. Korinsky wrote: > > ha, it was false alarm. > > I've waited for a while and it continue to working until it crashed as: > > Warn

Re: posix_spawn

irill > On 23. Dec 2023, at 19:24, Camm Maguire wrote: > > Just checking my understanding : 'gcl-devel' crashes in a different > place, and both of these are only with the posix_spawn patch, right? > > Take care, > > "Kirill A. Korinsky" writes: >

Re: posix_spawn

amm Maguire wrote: > > Greetings, and thanks so much! Could you please put a > printf("spawn");fflush(stdout); right before the patch and repeat? This > code should not be relevant at this point. > > Take care, > > "Kirill A. Korinsky" writes: > >&g

Re: Branch Version_2_7_0pre

macosx. This should be an optional feature. These macros > support disassembling code at the point of FPE errors. When all is > ready, you might try > >> (load (compile-file "../lsp/gcl_fpe_test.lsp")) > > Take care, > > "

Re: posix_spawn

w_pre_gcl > ./raw_pre_gcl ./ >> > > Then open up init_raw.lsp in some editor, and copy the forms therein one > at a time to the prompt. Lets focus on 'gcl-devel' at the moment. > Please let me know the step at which it fails. Keep in mind this file > takes a few second

Re: posix_spawn

ta On 23. Dec 2023, at 14:10, Kirill A. Korinsky <kir...@korins.ky> wrote:Let me summarise how it crashed on Xcode 15 with macOS 14.To test it I've used two gcl via MacPorts: - gcl which is 2.6.14 - gcl-devel which is the last available commit at master 01ed2e0b2f540031171d2258ddccb9

Re: posix_spawn

;symbol":"start","symbolLocation":1903,"imageIndex":0}]},{"id":12497313,"name":"com.apple.rosetta.exceptionserver","frames":[{"imageOffset":17972,"imageIndex":1}]}], "usedImages" : [ { "source" : "

Re: posix_spawn

well... seems that Xcode 15 with macOS 13+ requires additional patches.attached patch allows to pass configure but build failed at:COMPILER>/bin/sh: line 1: 15229 Illegal instruction: 4 at the attempt to run raw_pre_gcl. I'll try to investigate this (get the stacktrace) in next few days.Here I've a

Re: Branch Version_2_7_0pre

i386 1. it has missed AC_CHECK_SIZEOF(char,0) in configure.in 2. it has missed FPE_RLST for the case non x86_64, see config.h and 386-macosx.h -- wbr, Kirill > On 23. Dec 2023, at 01:40, Kirill A. Korinsky wrote: > > An attempt to build in on arm64 failed quite fast at ./con

Re: Branch Version_2_7_0pre

#include #include #include int main(int argc,char **argv,char **envp) { -- wbr, Kirill > On 23. Dec 2023, at 01:24, Kirill A. Korinsky wrote: > > I'd like to confirm that I successfully build gcl from commit > 01ed2e0b2f54003117

Re: Branch Version_2_7_0pre

you beyond the libc > issue. Please keep me informed. > > Take care, > > "Kirill A. Korinsky" writes: > >> On 22. Dec 2023, at 17:19, Camm Maguire wrote: >> >> On 3), after reading up on vfork, and examining your logs, it is indeed >> deprecated.

Re: posix_spawn

se it is working for me and could be a generic solution. > Did it eliminate those C compiler warnings? Can you run under gdb and > backtrace at the point asking for keyboard input? > > cd unixport > make raw_pre_gcl > gdb raw_pre_gcl > (gdb) r ./ > Take care, > > "Ki

Re: posix_spawn

something goes wrong here. It stuck like this: loading /Users/catap/src/gcl/gcl/unixport/../cmpnew/gcl_cmpspecial.lsp loading /Users/catap/src/gcl/gcl/unixport/../cmpnew/gcl_cmplam.lsp loading /Users/catap/src/gcl/gcl/unixport/../cmpnew/gcl_cmplet.lsp loading /Users/catap/src/gcl/gcl/unixport/../c

Re: Branch Version_2_7_0pre

> On 22. Dec 2023, at 17:19, Camm Maguire wrote: > > On 3), after reading up on vfork, and examining your logs, it is indeed > deprecated. This has been in use in 2.6 for many years -- have you been > applying a patch there as well? This patch was introduced by me at MacPorts when I upgraded G

Re: Branch Version_2_7_0pre

I've switched to b66c55853870ce15554bc4d9b911410dd07d8a451. readline still failing, inside config.logIn file included from conftest.c:89:In file included from /opt/local/include/readline/readline.h:36:/opt/local/include/readline/rltypedefs.h:71:29: error: unknown type name 'FILE'typedef int rl_getc

Re: Branch Version_2_7_0pre

ription: Binary data On 22. Dec 2023, at 00:25, Camm Maguire <c...@maguirefamily.org> wrote:Greetings, and thanks so much!  I think master should now address theseissues.  Please keep me informed.Take care,"Kirill A. Korinsky" <kir...@korins.ky> writes:With a few hacks (see attache

Re: Branch Version_2_7_0pre

0002-macOS-friendly-check-for-readline.patch Description: Binary data 0003-make-moder-clang-happy.patch Description: Binary data 0004-Use-FPE_SET_CTXT_ADDR-and-FPE_CLR_CTXT_CWD-only-when.patch Description: Binary data 0005-Reallu-disable-gprof.patch Description:

Re: Branch Version_2_7_0pre

first attempt to build it failed. I've used 5c7512ca471742c4e86894a3c6b5d93d02d31956 as local root with a few notes. 1. It required to --disable-gprof because configure failed with error: clang: error: the clang compiler does not support -pg option on versions of OS X 10.9 and later 2. It requi

Re: Branch Version_2_7_0pre

hen introduced. Perhaps we could debug these > issues further? > > Take care, > > "Kirill A. Korinsky" writes: > >> Thanks for a good news! >> >> I'm a maintainer all lisp ports at MacPorts (~200 the most popular packages >> I guess) and a

Re: Branch Version_2_7_0pre

that gcc changed inline semantics > around the same time and we followed. If I recall debian clang did > likewise. The -std=gnu89 comment seems apropos. > > Take care, > > "Kirill A. Korinsky" writes: > >> Any chance to have

Re: Branch Version_2_7_0pre

Any chance to have support of ASDF out of the box? -- wbr, Kirill > On 20. Dec 2023, at 23:24, Camm Maguire wrote: > > Greetings! This is to announce the pre-release of GCL 2.7.0. gcl27 > packages should appear on debian and derivatives shortly. One can > compile git branch Version_2_7_0pre

Re: Support of macOS at the last master

After commenting a target at gcl/h/386-macosx.defs it loads but crashes as: /Users/catap/src/gcl/gcl/unixport/raw_pre_gcl /Users/catap/src/gcl/gcl/unixport/ -libdir /Users/catap/src/gcl/gcl/ < foo GCL (GNU Common Lisp) April 1994 9489691 pages Building symbol table for /Users/catap/src/gcl/gcl/

Re: Support of macOS at the last master

ommit: [4d7046278b5fe95a92f83235335e2b0ca3415a97] support for GCL shared memory pools -- wbr, Kirill > On 1. Aug 2023, at 00:08, Kirill A. Korinsky wrote: > > well, > > the cause of duplicated symbols was -std=gnu89 which seems to be required a > while ago on macOS: https://t

Re: Support of macOS at the last master

well, the cause of duplicated symbols was -std=gnu89 which seems to be required a while ago on macOS: https://trac.macports.org/ticket/12906 without it, GCL fails as: /Users/catap/src/gcl/gcl/unixport/raw_pre_gcl /Users/catap/src/gcl/gcl/unixport/ -lib

Support of macOS at the last master

Good day,I'd like to share a series of patches which I've used to bring support of macOS back to GCL (attached).Anyway, this doesn't work yet. GCL fails to build with log like:libtool -static -o libpre_gcl.a ../o/alloc.o ../o/array.o ../o/assignment.o ../o/backq.o ../o/bds.o ../o/big.o ../o/bind.o