Menu
▾
▴
2 Attachments
#165 r6846 CSL-Reduce compilation failure on X86_64 macOS Big Sur 11.7.10
Few days ago I upgraded my r6834 local copy of Reduce to revision 6846.
As far as compilation on my MacBook Air M1 (with Sonoma 14.5) is concerned, everything was OK.
Compiling PSL-Reduce on X86_64 macOS Big Sur 11.7.10 is OK while, on the contrary, compiling CSL-Reduce fails while outputting the "generated-c" file "u35.cpp".
The last revision of CSL-Reduce which compiles without problems on X86_64 macOS Big Sur 11.7.10 is revision 6842. Starting from r6843, the compilation of CSL-Reduce always fails while outputting the "generated-c" file "u35.cpp" file at line 6089 with the following error
"!!! Aborting: newcslgc.cpp:266 page type not recognised"
None of the subsequent generated-c files is produced and the "reduce.app" is not built. The application "bootstrapreduce.app" seems to be OK, the application "csl.app" is present but something is missing inside it.
Related
An unspeakable misery for me is that I have not found a way to run and
hence test using versions of Mac OS other than the current one and that on
ARM not x86_64. I also note that Big Sur officially went out of support
from Apple at the end of November 2023!
So I can produce some suggestions that may help you but I am not in a
state where I can test/check/debug/provide-a-proper-fix. When I have tried
finding ways to run the Macintosh OS in a VM I have had big trouble (but
also a macbook does not have over-generous disc space so puttiong VMs on
it is nothing like as comfortable as on a PC where I can cheaply have a
big disc). And running x86_64 versions on an ARM mac is a no-go!
So here we go with ideas:
. When you have Reduce sources checked out using subversion you can go
into csl/cslbase and go "svn -r NNN update" so you get a previous version
of csl but all the bits of reduce via the packages directory are fully up
to date. YOu can hope that that builds OK!
When I have problems as nasty as the one you report I try that finding an
old working NNN and the latest failing MMM and bisect until I can track
exactly which revision introduced the problem. Note that some revisions
may be faulty because they introduced a typo and that they were followed
up very shortly after with a fix...
. I think that the Makefiles may all support an environment variable
CSLFLAGS that contains extra stuff to pass to the system when it is run.
Since this is a memory related issue you can try
export CSLFLAGS=-Knnn
where nnn is a memory size such as 3100M or 6G (megabytes or gigabytes)
that are a GUIDE not a precise amount for the system to use. Changing that
tends to change just when garbage collection happens. If you have enough
memory it can leave the system not needing to garbage collect at all. It
is usually not needed, but can be a lifesaver in situations like yours.
. Try configuring with "--with-csl --enable-debug" and see how far you
get. If you manage to make a reduce.img or all the
cslbuild/generated-c/u*.cpp files those would work for the non-debug
version too. And if it crashes there and you are SUPER keen you could then
try running under a debugger and working out exactly what happened and
suggest a fix!!!!!!!
I hope one of those paths gets you alive again.
Arthur
On Mon, 22 Jul 2024, Marco Ferraris wrote:
Related
Bugs: #165
Hi Arthur,
I have two X86_64 Macs:
1) MacBook Pro (Retina, 15-inch, Mid 2014) with 16 GB of ram and 1 TB SSD
2) iMac (Retina 5K, 27-inch, Late 2014) with 32 GB of ram and 1.12 TB Fusion Drive
The last supported os on these machines is macOS Big Sur 11.7.10 and they work perfectly well.
As I wrote in my previous message, the last revision of CSL-Reduce which compiles without problems on these machines is revision 6842 and the revision which introduces the problem is revision 6843.
As you suggested, I tried "export CSLFLAGS=-K6G" before cofiguring and compiling CSL-Reduce (both native and universal) . Compilation was OK on the MacBook Pro for revisions 6843, 6844 and 6846. Now I'll try compiling on the iMac.
Best regards
Marco
I will inspect what changes between 6842 and 6843 to see if I can spot
anything, and will try a few more builds on Linux and Windows.
But the things being changes from 6842-43 should not (I think) be such as
to hit older Macs but spare everybody else. A problem like that may be
totally generic and it is just bad luck that it shows up on those
machines, but that does not alter the fact that tracking it down when I
can not trivially run old released of macOS to check there makes it hard
for me to support. Apologies.
In some same sense that there may be a latest supported macOS there could
be a latest supported CSL. But I do not think this is a deliberate version
of that. I guess I should also say that I find the Mac the hardest
platform to debug low level issues on with Linux by a very long way the
one I can cope with best, so really I need a crash that I can generate
repeatably on Linux (under the "rr" reverse debugger...)
I agree that there are systems that Apple refuses to provide security
updates to but that otherwise continue to work as well as they did before.
I guess they really want people to go out and buy new hardware. With
Windows 10 vs 11 Microsoft are following the same nasty path.
Arthur
On Mon, 22 Jul 2024, Marco Ferraris wrote:
Related
Bugs: #165