Hi Kevin,
That still works great.
For anybody who needs macports over homebrew I did these extra steps to select
the correct compiler:
sudo port install gcc14
port select --list gcc
sudo port select --set gcc mp-gcc14
hash -r
Cheers
David
> On 25 Feb 2025, at 7:07 AM, Kevin Lin <kky...@alum.mit.edu> wrote:
>
> 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.
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>
>>> --
>>
>> --
>
> --
