Hi David, Of course! I decided to write up some notes and put it up. Here is a patch that worked for me with MIT Scheme 12.1 on macOS 15.3:
https://github.com/kkylin/mit-scheme-intel-mac-patch/blob/main/mit-scheme-12.1-patch (save this in mit-scheme-12.1/src and run `patch < mit-scheme-12.1-patch`) More detailed notes here: https://github.com/kkylin/mit-scheme-intel-mac-patch?tab=readme-ov-file It's been a while since I last did this, so I may have missed something. Comments & questions welcome! (A bit busy at work these couple weeks so I may be slow to respond...) Cheers, Kevin -----Original Message----- From: David Gray <dg...@iesl.forth.gr> Cc: mit-scheme-users@gnu.org Hi, can you share the details of this? I assume some changes to the Makefile for the linking. My method was such a mess I don’t think that it is very repeatable. David > On 22 Dec 2024, at 12:05 PM, Kevin Lin <kky...@alum.mit.edu> wrote: > > Hi David, > > Your message inspired me (mid-vacation!) to try to > compile Scheme with gcc (gcc-14 via Homebrew). I did > manage to get it to work. As you said, it was > necessary to comment out some code (gcc seems unhappy > with Apple's header files; looks to me like Core > Foundation things that are needed only for building a > stand-alone Mac app, which I don't use). Doing things > this way leads to a compiler that seems to function > just fine in my testing. > > I also tried the following experiments: > > 1) Compile the microcode using gcc but linking with > clang > > 2) Compile the microcode using clang but linking with > gcc (this does not require commenting out any code) > > (1) leads to the same compiler issues as before, while > (2) again seems to work fine. So maybe it's a linkage > issue, rather than compilation per se? Anyway it > seems this is one way to build a working MIT Scheme on > Intel Macs on a recent macOS. It's a little clunky, > but I don't know enough about how linking works to > find a better solution. > > Kevin > > -----Original Message----- > From: David Gray <dg...@iesl.forth.gr> > Cc: mit-scheme-users@gnu.org > > For what it's worth, it is a problem with the apple > compiler. I managed to get a butchered version working by > using gcc13 with macports. > I just chopped out the lines with errors in the source, > copied the all.com from the previous version. Unlikely as it > seems this compiles scheme code correctly even with the > usual-integrations. However I’m not expert enough to go > anywhere further with this information. > >> On 10 Dec 2024, at 6:23 AM, Kevin Lin <kky...@alum.mit.edu> wrote: >> >> Thanks David. I've been doing something similar to >> you, but using a version of the work-around in my >> first msg (despite my own disclaimers). So far it >> seems to work fine and I can get by with it. >> -Kevin >> >> >> -----Original Message----- >> From: David Gray <dg...@iesl.forth.gr> >> Cc: mit-scheme-users@gnu.org >> >> I think you are correct in that it is saving that is the >> problem. I really just want a couple of slow functions to be >> compiled, so after digging around in the source I found >> compile-procedure which does what I need for the >> moment. Just load up the function, compile-procedure, then >> run it. >> >> >> >> >>> On 4 Dec 2024, at 10:43 PM, Kevin Lin <kky...@alum.mit.edu> wrote: >>> >>> Sorry, two things I forgot to say: >>> >>> - If scode that's been directly compiled (as in my >>> example, and as opposed to loading it from a .bin >>> file generated by SF) is then compiled into native >>> code via say compile-scode, it does seem to run just >>> fine. But saving to file (via fasdump) and >>> reloading leads to the same problems. >>> >>> - Not necessarily recommending these kludges as a >>> work-around for anyone else having similar issues -- >>> I don't know MIT Scheme internals and haven't tested >>> these things; the kludges came about as an effort to >>> isolate the issue. >>> >>> Kevin >>> >>> -----Original Message----- >>> To: mit-scheme-users@gnu.org >>> >>> Hi all, >>> >>> I'm trying to build and run MIT/GNU Scheme 12.1 on an Intel >>> Mac running Sequoia (15.1). I've had similar issues as >>> described on this thread: >>> >>> https://lists.gnu.org/archive/html/mit-scheme-users/2023-10/msg00004.html >>> >>> I've been digging around this for a bit, so this is long. >>> I've broken this into sections. Details on how I built >>> Scheme on my machine come at the end. Any insights or just >>> knowing that someone has managed to get 12.1 running on a >>> recent macOS would be great. >>> >>> Thanks! >>> >>> Kevin <kky...@alum.mit.edu> >>> >>> *MAIN SYMPTOMS* >>> >>> Here is a little transcript of what I get: >>> >>> #| >>> (cf "fact.scm") >>> >>> ;Generating SCode for file: "fact.scm" => "fact.bin"... done >>> ;Compiling file: "fact.bin" => "fact.com"... done >>> ;Unspecified return value >>> >>> 1 ]=> (load "fact.com") >>> >>> ;Loading "fact.com"... >>> ;The object fact, passed as an argument to >>> return-address->stack-frame-type, is not in the correct >>> range. >>> ;To continue, call RESTART with an option number: >>> ; (RESTART 1) => Return to read-eval-print level 1. >>> |# >>> >>> The file "fact.scm" is something more or less straight from >>> SICP: >>> >>> #| >>> (declare (usual-integrations)) >>> >>> (define (fact n) >>> (if (> n 1) >>> (* n (fact (- n 1))) >>> 1)) >>> |# >>> >>> Moreover, there appear to be issues affecting SF as well: >>> >>> #| >>> 1 ]=> (sf "fact.scm") >>> >>> ;Generating SCode for file: "fact.scm" => "fact.bin"... done >>> ;Unspecified return value >>> >>> 1 ]=> (pp (fasload "fact.bin")) >>> >>> ;Loading "fact.bin"... done >>> (define (fact n) >>> (if (%record n 1) >>> (%record n (fact (%record n))) >>> 1)) >>> ;Unspecified return value >>> |# >>> >>> If I remove (declare (usual-integrations)) then it seems to >>> be ok: >>> >>> #| >>> 1 ]=> (sf/system "fact.scm") >>> >>> ;Generating SCode for file: "fact.scm" => "fact.bin"... >>> ; This program does not have a USUAL-INTEGRATIONS declaration. >>> ; Without this declaration, the compiler will be unable to perform >>> ; many optimizations, and as a result the compiled program will be >>> ; slower and perhaps larger than it could be. Please read the MIT >>> ; Scheme User's Guide for more information about USUAL-INTEGRATIONS. >>> ;... done >>> ;Unspecified return value >>> >>> 1 ]=> (pp (fasload "fact.bin")) >>> >>> ;Loading "fact.bin"... done >>> (define (fact n) >>> (if (> n 1) >>> (* n (fact (- n 1))) >>> 1)) >>> ;Unspecified return value >>> |# >>> >>> but CF continues to fail: >>> >>> #| >>> 1 ]=> (cf/system "fact.scm") >>> >>> ;Generating SCode for file: "fact.scm" => "fact.bin"... >>> ; This program does not have a USUAL-INTEGRATIONS declaration. >>> ; Without this declaration, the compiler will be unable to perform >>> ; many optimizations, and as a result the compiled program will be >>> ; slower and perhaps larger than it could be. Please read the MIT >>> ; Scheme User's Guide for more information about USUAL-INTEGRATIONS. >>> ;... done >>> ;Compiling file: "fact.bin" => "fact.com"... done >>> ;Unspecified return value >>> >>> 1 ]=> (load "fact.com") >>> >>> ;Loading "fact.com"... >>> ;The object fact, passed as an argument to >>> return-address->stack-frame-type, is not in the correct >>> range. >>> ;To continue, call RESTART with an option number: >>> ; (RESTART 1) => Return to read-eval-print level 1. >>> |# >>> >>> *IS FASDUMP THE PROBLEM?* >>> >>> One thing I noticed is that if I took a .bin or .com file >>> compiled on my Linux box and loaded it on my Intel Mac, it >>> works just fine: this code (and more complicated programs) >>> runs without a hiccup, and pretty-printing the .bin file >>> looks fine to me. It suggests the issue *might* be centered >>> around saving binary files. Digging around more, I found >>> that if I bypass the FASDUMP defined in fasdump.c, SF >>> appears to be ok again. Here's a little kludge that does >>> that. >>> >>> (define *target-fasl-format* >>> (eval '(target-fasl-format) (->environment cbf))) >>> >>> (define (fasdump-kludge obj file) >>> (portable-fasdump obj file *target-fasl-format*)) >>> >>> and what we find is this: >>> >>> #| >>> 1 ]=> (define fact-scode >>> ;; compile SCode without saving to file >>> (eval '(sf/file->scode "fact.scm" "" #f '()) >>> (package/environment >>> (find-package '(scode-optimizer top-level))))) >>> ;Value: fact-scode >>> >>> 1 ]=> (pp fact-scode) ;; looks ok to me >>> (define (fact n) >>> (if (&> n 1) >>> (&* n (fact (-1+ n))) >>> 1)) >>> ;Unspecified return value >>> >>> 1 ]=> (fasdump-kludge fact-scode "fact.bin") ;; now save to file >>> >>> ;Unspecified return value >>> >>> 1 ]=> (pp (fasload "fact.bin")) ;; reload and look >>> >>> ;Loading "fact.bin"... done >>> (define (fact n) >>> (if (&> n 1) >>> (&* n (fact (-1+ n))) >>> 1)) >>> ;Unspecified return value >>> >>> |# >>> The kludge doesn't work for compiled expressions and I >>> didn't test it on a .com file. I've also dug around >>> fasdump.c but I don't understand the microcode and don't >>> know where to start tracking down the issue. >>> >>> Anecdotally, the native code compiler worked just fine in >>> Monterey and earlier versions of macOS. >>> >>> *MORE SYMPTOMS* >>> >>> 1. One can get different errors by (i) adding more >>> definitions to fact.scm, and (ii) selecting which >>> primitives (+, *, >) get integrated. I didn't include >>> all the cases. >>> >>> 2. DISK-SAVE also fails, but bands saved on working >>> installations (e.g., ScmUtils) work just fine. >>> >>> *HOW I BUILT SCHEME* >>> >>> I use Apple's "gcc", which (I think) is just an alias for >>> clang. I massage various env vars (happy to share >>> config.log), but none of that seems super important. What >>> *is* important is to set SDKROOT to >>> >>> `xcrun --sdk macosx --show-sdk-path` >>> >>> or clang won't compile the microcode. This may have >>> something to do with my having GCC installed (via Homebrew). >>> Incidentally, I haven't tried uninstalling gcc as that would >>> break too many things, but I did try unlinking gcc and it >>> didn't make a difference to the behavior above. >>> >>> In case it matters, all this is on a 2015 Intel MBP. I get >>> the same behavior on an M2 Mac via Rosetta, and on older >>> Intel Macs on Sequoia + OCLP. >>> >>> -- >>> >>> -- >>> >> >> -- > > -- --
