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