Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults

[John Paul Adrian Glaubitz]

Control: retitle -1 guile-3.0: Please include patch to fix FTBFS on 32-bit BE systems
Control: tags -1 +patch

Hello!

The attached patch fixes the problem for me. It was suggested by Efraim Flashner
in the corresponding upstream bug report [1].

It simply adds "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS in bootstrap/
Makefile.am. I have tried coming up a with a solution to add these flags on hppa,
m68k and powerpc only but I couldn't find any suitable solution.

However, I would assume that passing these flags to the bootstrap build won't hurt
as the second stage is built with -O2 anyway and the above flags are not being used
in this case.

Could you include this patch or a possible better version in the next guile-3.0 upload?

Adrian

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214

[John Paul Adrian Glaubitz]

Hello!

Post by John Paul Adrian Glaubitz
The attached patch fixes the problem for me. It was suggested by Efraim Flashner
in the corresponding upstream bug report [1].
It simply adds "-Oresolve-primitives -Ocps" to GUILE_OPTIMIZATIONS in bootstrap/
Makefile.am. I have tried coming up a with a solution to add these flags on hppa,
m68k and powerpc only but I couldn't find any suitable solution.
However, I would assume that passing these flags to the bootstrap build won't hurt
as the second stage is built with -O2 anyway and the above flags are not being used
in this case.

Any chance this patch could be included for the next upload?

This bug is currently blocking package builds on powerpc.

Adrian

[Rob Browning]

Post by John Paul Adrian Glaubitz
Any chance this patch could be included for the next upload?
This bug is currently blocking package builds on powerpc.

I'm working on 3.0.8, and I'll see about including it there, either in
the initial upload, or subsequently. I also plan to add the other
"disable threads" fix for the relevant architectures.

Thanks, and apologies for the delay.

[Rob Browning]

Post by John Paul Adrian Glaubitz
Could you include this patch or a possible better version in the next guile-3.0 upload?

As mentioned, I'm working on 3.0.8, and the bootstrap process has
changed somewhat to support reproducible builds. So I went ahead and
uploaded 3.0.8-1 without this patch, and then I hoped, if you have time,
you might be able to test that and see if we need to make adjustments to
the fix. In particular, guile now has
{bootstrap,stage0,stage1,stage2}/Makefile.am.

It may be that we only need to adjust a subset of these (say bootstrap
and/or stage0)...

Oh, and I'm not sure it's working exactly right yet, but I'd been toying
with a more selective approach that works with automake's if/then
restrictions via an AM_CONDITIONAL. Of course we'll still need to
figure out which Makefiles we need to adjust.

[John Paul Adrian Glaubitz]

Hi Rob!

Post by Rob Browning
Oh, and I'm not sure it's working exactly right yet, but I'd been toying
with a more selective approach that works with automake's if/then
restrictions via an AM_CONDITIONAL. Of course we'll still need to
figure out which Makefiles we need to adjust.

I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
chroot, but unfortunately it didn't work:

In unknown file:
13 (_ #<procedure ef2c1210 at ice-9/eval.scm:330:13 ()> # #)
12 (_ #<procedure ef2c5820 at ice-9/eval.scm:330:13 ()> # #)
In ice-9/eval.scm:
619:8 11 (_ #(#(#<directory (system base compile) ef2a6b90> # ?)))
196:35 10 (_ #(#(#<directory (system base compile) ef2a6b90> ?) #))
In unknown file:
9 (_ #<procedure ef2d70b0 at ice-9/eval.scm:330:13 ()> # #)
8 (_ #<procedure ef1764e0 at ice-9/eval.scm:330:13 ()> # #)
7 (_ #<procedure ef1763c0 at ice-9/eval.scm:330:13 ()> # #)
In ice-9/eval.scm:
202:35 6 (_ #(#(#<directory (system base compile) ef2a6b90> ?) ?))
In language/tree-il/optimize.scm:
56:6 5 (_ _ #<directory (language cps intset) ee45d6e0>)
In language/tree-il.scm:
573:16 4 make[4]: *** [Makefile:2419: language/cps/intset.go] Segmentation fault

FWIW, you can access the porterbox yourself using your Debian SSH account.

Adrian

[John Paul Adrian Glaubitz]

Hi Rob!

Post by John Paul Adrian Glaubitz
I tested your proposed patch on the porterbox perotto.debian.net in a powerpc

I think this check is wrong:

diff --git a/configure.ac b/configure.ac
index 827e1c09d..dec060414 100644
--- a/configure.ac
+++ b/configure.ac
@@ -369,6 +369,9 @@ else
fi
AC_SUBST([SCM_I_GSC_T_PTRDIFF])

+AM_CONDITIONAL([DEB_GUILE_32_BIT_BIG_ENDIAN],
+ [test "$ac_cv_words_bigendian" && test "$ac_cv_sizeof_void_p" -lt 8])
+
AC_CHECK_HEADERS([stdatomic.h])

AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])

It looks like the correct variable name for the big-endian check is

$ac_cv_c_bigendian

Adrian

[John Paul Adrian Glaubitz]

Hi!

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
I tested your proposed patch on the porterbox perotto.debian.net in a powerpc

diff --git a/configure.ac b/configure.ac
index 827e1c09d..dec060414 100644
--- a/configure.ac
+++ b/configure.ac
@@ -369,6 +369,9 @@ else
fi
AC_SUBST([SCM_I_GSC_T_PTRDIFF])
+AM_CONDITIONAL([DEB_GUILE_32_BIT_BIG_ENDIAN],
+ [test "$ac_cv_words_bigendian" && test "$ac_cv_sizeof_void_p" -lt 8])
+
AC_CHECK_HEADERS([stdatomic.h])
AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
It looks like the correct variable name for the big-endian check is
$ac_cv_c_bigendian

Why not just use the result of this check?

AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
SCM_PREBUILT_BINARIES=
case "$ac_cv_c_bigendian-$ac_cv_sizeof_void_p" in
yes-8) SCM_PREBUILT_BINARIES=64-bit-big-endian;;
yes-4) SCM_PREBUILT_BINARIES=32-bit-big-endian;;
no-8) SCM_PREBUILT_BINARIES=64-bit-little-endian;;
no-4) SCM_PREBUILT_BINARIES=32-bit-little-endian;;
*) AC_MSG_ERROR([Unexpected endianness+pointer size combination.])
esac
AC_MSG_RESULT($SCM_PREBUILT_BINARIES)
AC_SUBST([SCM_PREBUILT_BINARIES])

Adrian

[John Paul Adrian Glaubitz]

Hi Rob!

The attached patch seems to work correctly. I had to escape the whole statements
so that they are not interpreted by automake.

Adrian

[John Paul Adrian Glaubitz]

Hi Rob!

Post by John Paul Adrian Glaubitz
The attached patch seems to work correctly. I had to escape the whole statements
so that they are not interpreted by automake.

I have verified that the attached patch fixes the build on 32-bit PowerPC (powerpc).

Adrian