Menu
▾
▴
#167 r6873 and r6874 compilation of CSL-Reduce fails on macOS
Compiling r6873 and r6874 CSL-Reduce, both on X86_64 macOS Big Sur 11.7.10 and M1 macOS Sequoia 15.0, fails because of a missing file.
The error is the following:
" clang: error: no such file or directory: '~/sw/reduce-algebra/trunk/canary.c' "
Best regards,
Marco Ferraris
Hi Arthur,
after installing macOS Sequoia 15.0, I reinstalled from scratch Xcode 16.0 with its CommandLineTools and MacPorts. Then I tried to reinstall the universal ports needed for building Reduce.
As you pointed out, installing "ossp-uuid+universal" fails on M1 macOS Sequoia 15.0. This prevents the possibility of installing "Xft2+universal" and "fontconfig+universal" and quite a few other universal ports. As a consequence, the compilation of the universal version of CSL-Reduce fails.
I was able to compile only native versions of CSL-Reduce (r6870, r6872 and, now, r6875) on my M1 MacBook Air with macOS Sequoia 15.0 (./configure --with-csl --disable-universal; make). The antediluvian "reduce.tst" test file is then processed without problems;
The last revision of CSL-Reduce I compiled on my win10 laptop was r6872, where the file "canary.c" was not yet present.
As far as compiling and running native versions (r6870, r6872 and r6875) of CSL-Reduce and PSL-Reduce on X86_64 Big Sur are concerned everything works fine.
Compiling universal versions (r6870, r6872 and r6875) of CSL-Reduce on X86_64 Big Sur works fine. However I had problems with r6872 and r6875 versions because "run.sh", which was modified in r6871, tries to find the compiled app "reduce" in the wrong directory:
if test -x /sw/reduce-algebra/trunk/scripts/../cslbuild/x86_64-mac_11_big_sur-darwin20.6.0/csl/reduce
if test -x /sw/reduce-algebra/trunk/scripts/../cslbuild/x86_64-mac_11_big_sur-darwin20.6.0/csl/reduce
try2=/sw/reduce-algebra/trunk/scripts/../cslbuild/x86_64**/csl/reduce
while the "reduce" app is
/sw/reduce-algebra/trunk/scripts/../cslbuild/universal-mac_11_big_sur-darwin20.6.0/csl/reduce
Using the file "run.sh" from r6870 temporarily solves the problem of running universal CSL-Reduce.
Best regards
Marco Ferraris
On Tue, 1 Oct 2024, Marco Ferraris wrote:
Yes - that is a REAL PAIN. I was able to edit the ossp-uuuid sources
in the place where macports had put them and get a version to build and
with that I could cope - but I have not explained to people what I did
because it was not a coherent path - I was in hope and expectation that
the macports ossp-uuid+universal would be corrected soon enough. I have
not send a report to macports about this. I suspect that by now somebody
should!
To get that to behave I had to change things because the version of libffi
that I was using (so I could guarantee I had a static library version, and
that so that reduce binaries did not need extra dynamic libraries present
that might not be installed for everybody) would not build with the latest
MacOS and Xcode. Things like these where software components that are not
really mine suffer from incompatible changes that Apple make leave me
disliking that platform quite a lot!
Apple had not messed up as many things then. And maybe universal was not
needed if you were on an Intel mac, so the delicacy and pain that that
brings in do not hit you there as much.
Have a flamed about how much pain the Mac gives me for a machine that I do
not use as a main computer for anything much? Thank you for your report
and I will at some stage try to sort things out but there are time I feel
about ready to give up all pretence of Mac support with
(1) MacOS/Xcode changes that break existing code both of mine and
in libraries that I use;
(2) The complication of "universal" builds;
(3) In the past I have, when I tried, failed to get testing versions of
MacOS going in virtual machines, and even if I can with a disk that
is small by normal PC standards that clogs up my machine to an undue
extent, so testing compatibility is essentially impossible for me;
(4) The debugging tools I am used to are a big pain to use with the
Mac wanting things signed. By that I mean "gdb" and these days I
really like to use "rr" so I can use backwards and well as forwards
debugging. And being a dinosaur but also because the Mac comes below
both Windows and Linux in my interests I do not use the Xcode fancy
cleverness (which really wants a huge screen not a laptop sized one).
Apologies for the rant!
Possible solutions for solving the problem of running universal csl-reduce on x86_64 macOS 11 Big Sur.