Hi Arthur,
compiling r6985 and r6986 csl-reduce fails on my M1 MacBook Air running macOS Sequoia 15.3.1 (using macports). The problem looks like to be connected with compiling the file 'jit.cpp'.
I have been creating that file and putting in a rapid sequence of updates
to it. I will check (it will probably be tomorrow now since I am part way
through fully reinstalling macports stuff!)
Arthur
On Sat, 15 Feb 2025, Marco Ferraris wrote:
[bugs:#174] compiling r6985 and r6986 csl-reduce fails on macOS
Status: open Group: Created: Sat Feb 15, 2025 05:23 PM UTC by Marco Ferraris Last Updated: Sat Feb 15, 2025 05:23 PM UTC Owner: nobody Attachments:
Hi Arthur,
compiling r6985 and r6986 csl-reduce fails on my M1 MacBook Air running macOS Sequoia 15.3.1 (using macports). The problem looks like to be connected with compiling the file 'jit.cpp'.
A follow-up explaininig a bit morte what I have been up to.
For the Mac I have been attempting to get things so that Reduce can be
built with a homebrew toolchain as an alternative to macports. My current
state on that is that first I do not see making an universal binary as
easy using homebrew. And then I have some students and I have been trying
to get that going on three macbooks where we have been trying rather hard
to ensure that the brew setup matches on each, but on one machine things
work and on the other two not, but with different linking failures. That
for now has left me fairly seriously twitchy about homebrew!
And then alonng with that I have been adjusting the configure and build
steps with a view that the code should build using macports when macports
has been installed somewhere other than in /opt/local - for instance
either in your own user directory or on an external drive. The reinstall
of all of macports that I am doing now is such a custom install so I can
check that better...
Then the file jit.cpp and the inclusion of libraries/asmjit is part of
a project that is at present at a very early stage for seeing if it is
first feasible and then worthwhile to have a just-in-time compiler from
the existing CSL bytecodes into native machine code. The setup is such
that it has a framework for use on Windows-x86_64/mingw64,
Windows-cygwin(64), Linux-x86_64, Linux-arm64 and both Intel and ARM macs.
With a current view that the details could be filled in for each of those
one at a time. I have a Grand Plan for this but at best a skeletal
framework of code that does not actually include anything that generates
code. And it is not at all clear that it will ever end up working and
useful. But the changes I need to make to the body of CSL to provode
"hooks" for it carry risks of what I hope will be transient disruption to
the rest of the world.
When I make significant changes I obviously try to see if things rebuild
on several architectures. As you can imagine that is tedious so I admit
that sometimes I wait for a while. But to get versions to the different
machines needed for testing I tend to want to check local updates in and
then fetch for testing - aware that I may need to then check in fixes. So
I know there can be (hopefully short lived) bad versions on sourceforge.
But a good thing about subversion is that those who are updating from
there and building from source can easily revert to a previous checking,
in particular sometimes working with a few days older version of the
csl/cslbase directory then of the packages one...
Arthur
On Sat, 15 Feb 2025, Arthur Norman wrote:
I have been creating that file and putting in a rapid sequence of updates
to it. I will check (it will probably be tomorrow now since I am part way
through fully reinstalling macports stuff!)
Arthur
[bugs:#174] compiling r6985 and r6986 csl-reduce fails on macOS
I have been creating that file and putting in a rapid sequence of updates
to it. I will check (it will probably be tomorrow now since I am part way
through fully reinstalling macports stuff!)
Arthur
On Sat, 15 Feb 2025, Marco Ferraris wrote:
Related
Bugs: #174
A follow-up explaininig a bit morte what I have been up to.
For the Mac I have been attempting to get things so that Reduce can be
built with a homebrew toolchain as an alternative to macports. My current
state on that is that first I do not see making an universal binary as
easy using homebrew. And then I have some students and I have been trying
to get that going on three macbooks where we have been trying rather hard
to ensure that the brew setup matches on each, but on one machine things
work and on the other two not, but with different linking failures. That
for now has left me fairly seriously twitchy about homebrew!
And then alonng with that I have been adjusting the configure and build
steps with a view that the code should build using macports when macports
has been installed somewhere other than in /opt/local - for instance
either in your own user directory or on an external drive. The reinstall
of all of macports that I am doing now is such a custom install so I can
check that better...
Then the file jit.cpp and the inclusion of libraries/asmjit is part of
a project that is at present at a very early stage for seeing if it is
first feasible and then worthwhile to have a just-in-time compiler from
the existing CSL bytecodes into native machine code. The setup is such
that it has a framework for use on Windows-x86_64/mingw64,
Windows-cygwin(64), Linux-x86_64, Linux-arm64 and both Intel and ARM macs.
With a current view that the details could be filled in for each of those
one at a time. I have a Grand Plan for this but at best a skeletal
framework of code that does not actually include anything that generates
code. And it is not at all clear that it will ever end up working and
useful. But the changes I need to make to the body of CSL to provode
"hooks" for it carry risks of what I hope will be transient disruption to
the rest of the world.
When I make significant changes I obviously try to see if things rebuild
on several architectures. As you can imagine that is tedious so I admit
that sometimes I wait for a while. But to get versions to the different
machines needed for testing I tend to want to check local updates in and
then fetch for testing - aware that I may need to then check in fixes. So
I know there can be (hopefully short lived) bad versions on sourceforge.
But a good thing about subversion is that those who are updating from
there and building from source can easily revert to a previous checking,
in particular sometimes working with a few days older version of the
csl/cslbase directory then of the packages one...
Arthur
On Sat, 15 Feb 2025, Arthur Norman wrote:
Related
Bugs: #174