Re: [CLN-list] Error building cln on M1 Mac
Ron Garret wrote:
I took the plunge and installed autoconf and all the other thing you need to build the git version, and that worked.
So I guess the only issue is that the latest official release is a little behind.
Good finding! Indeed, the fix was committed by Richard on 2021-11-04. Bruno
Hi, On 3/5/23 20:49, Bruno Haible wrote:
Ron Garret wrote:
I took the plunge and installed autoconf and all the other thing you need to build the git version, and that worked.
Just to make sure: That means it passes 'make check' even without the NO_ASM flag, right?
So I guess the only issue is that the latest official release is a little behind.
Thanks, Ron, for this feedback. It's appreciated. Sorry, I don't have or personally care much about Macs, so, although I try to fix issues the status is often just unknown to me.
Good finding! Indeed, the fix was committed by Richard on 2021-11-04.
Well. it's been a while. I guess it's time to tag and release what's in git. (Or is this too outdated and we should just tell people to build off from git? After all, it's mostly bug-fixing. Comments welcome!) -richy.
Hi Richard,
I guess it's time to tag and release what's in git. (Or is this too outdated and we should just tell people to build off from git? After all, it's mostly bug-fixing. Comments welcome!)
I would say, it's time to make a release. In my understanding - It would be good to upgrade to Autoconf 2.71 and Libtool 2.4.7, since these releases include a large number of fixes. - Then I offer to spend a day or two testing the thing on the current set of platforms, with current compilers (from Linux/arm over Solaris 11 to Android, with g++ 12 and clang 15, etc.) "just tell people to build off from git" increases the installation effort, compared to a release tarball. Distros like Debian also prefer a release tarball, I think? Bruno
Dear Bruno, On 3/5/23 21:59, Bruno Haible wrote:
I would say, it's time to make a release.
Fine, let's do it! (I was just wondering about when the last tag was placed in CLisp...)
In my understanding - It would be good to upgrade to Autoconf 2.71 and Libtool 2.4.7, since these releases include a large number of fixes.
That should happen automatically with what's in git, I think.
- Then I offer to spend a day or two testing the thing on the current set of platforms, with current compilers (from Linux/arm over Solaris 11 to Android, with g++ 12 and clang 15, etc.)
Good idea. Let's first see what the current status is. FWIW, Debian's status is at <https://buildd.debian.org/status/package.php?p=cln> where architectures hppa, sparc, sparc64, arm, armel, and armhf were built with -DNO_ASM for various reasons. For arm*, this should not be necessary any more, I dare to hope.
"just tell people to build off from git" increases the installation effort, compared to a release tarball. Distros like Debian also prefer a release tarball, I think?
Well, personally, with my distro maintainer hat on, I do appreciate clearly defined releases. -richy.
Richard B. Kreckel wrote:
(I was just wondering about when the last tag was placed in CLisp...)
The world of C++ compilers (prerequisite of CLN) is evolving faster than the world of C compilers (prerequisite of GNU clisp). Therefore they can have different release frequencies.
In my understanding - It would be good to upgrade to Autoconf 2.71 and Libtool 2.4.7, since these releases include a large number of fixes.
That should happen automatically with what's in git, I think.
Please give me a tarball. So that what I test is as close as possible to what you will release — no arbitrary differences. Thanks.
FWIW, Debian's status is at <https://buildd.debian.org/status/package.php?p=cln> where architectures hppa, sparc, sparc64, arm, armel, and armhf were built with -DNO_ASM for various reasons. For arm*, this should not be necessary any more, I dare to hope.
I will test each. I'll build without -DNO_ASM by default, and then see whether -DNO_ASM is needed. Bruno
On 3/6/23 00:05, Bruno Haible wrote:
Please give me a tarball. So that what I test is as close as possible to what you will release — no arbitrary differences. Thanks.
Hop! <https://in.terlu.de/~kreckel/cln-1.3.7-pre.tar.bz2> -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Richard B. Kreckel wrote:
Please give me a tarball. So that what I test is as close as possible to what you will release — no arbitrary differences. Thanks.
Muchas gracias. Toda raba. Vielen Dank! Bruno
On 3/6/23 13:50, Bruno Haible wrote:
Richard B. Kreckel wrote:
Please give me a tarball. So that what I test is as close as possible to what you will release — no arbitrary differences. Thanks.
Muchas gracias. Toda raba. Vielen Dank!
FWIW, the ARM Linux platforms seem to be okay now without -DNO_ASM: https://buildd.debian.org/status/package.php?p=cln&suite=experimental -richy.
Hi Richy,
Unfortunately, when I build this with CC="gcc -ftrapv" CXX="g++ -ftrapv", I find that it invokes undefined behaviour (due to signed integer overflow during left-shifting). It means that compilers can miscompile this code as they see fit. The fix is to change the bit() macro. Of course I would like to do this fix before the next release. But before doing that, I need to increase the test coverage (more 'exam_*' tests), to make sure that the change doesn't break things. Then only I'll test on the umpteen various architectures. It will take a couple of weeks (because I'm also busy with other packages). Bruno
Hi Bruno, On 3/15/23 23:07, Bruno Haible wrote:
Unfortunately, when I build this with CC="gcc -ftrapv" CXX="g++ -ftrapv", I find that it invokes undefined behaviour (due to signed integer overflow during left-shifting). It means that compilers can miscompile this code as they see fit.
The fix is to change the bit() macro. Of course I would like to do this fix before the next release. But before doing that, I need to increase the test coverage (more 'exam_*' tests), to make sure that the change doesn't break things.
Then only I'll test on the umpteen various architectures.
It will take a couple of weeks (because I'm also busy with other packages).
Should we wait for this before releasing 1.3.7? -richy.
participants (2)
-
Bruno Haible
-
Richard B. Kreckel