Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#977223: guile-3.0: FTBFS on hppa - segmentation faults
2 views
Skip to first unread message
John Paul Adrian Glaubitz
Oct 3, 2021, 6:50:03 AM10/3/21
to
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
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
Feb 16, 2022, 10:20:02 AM2/16/22
to
Hello!
On 10/3/21 12:43, John Paul Adrian Glaubitz wrote:
> 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
On 10/3/21 12:43, John Paul Adrian Glaubitz wrote:
> 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.
This bug is currently blocking package builds on powerpc.
Adrian
Rob Browning
Feb 27, 2022, 1:40:02 AM2/27/22
to
John Paul Adrian Glaubitz <glau...@physik.fu-berlin.de> writes:
> 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
> Any chance this patch could be included for the next upload?
>
> This bug is currently blocking package builds on powerpc.
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
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning
Feb 27, 2022, 11:20:03 PM2/27/22
to
> 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
Feb 28, 2022, 4:00:02 AM2/28/22
to
Hi Rob!
On 2/28/22 05:13, Rob Browning wrote:
> 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
On 2/28/22 05:13, Rob Browning wrote:
> 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.
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
Feb 28, 2022, 5:30:02 AM2/28/22
to
Hi Rob!
On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
> chroot, but unfortunately it didn't work:
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
On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
> chroot, but unfortunately it didn't work:
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
John Paul Adrian Glaubitz
Feb 28, 2022, 5:30:02 AM2/28/22
to
Hi!
On 2/28/22 11:16, John Paul Adrian Glaubitz wrote:
> On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
>> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
>> chroot, but unfortunately it didn't work:
>
> 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
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])
On 2/28/22 11:16, John Paul Adrian Glaubitz wrote:
> On 2/28/22 09:53, John Paul Adrian Glaubitz wrote:
>> I tested your proposed patch on the porterbox perotto.debian.net in a powerpc
>> chroot, but unfortunately it didn't work:
>
> 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
AC_MSG_CHECKING([for which prebuilt binary set to use during bootstrap])
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])
John Paul Adrian Glaubitz
Mar 1, 2022, 2:10:03 AM3/1/22
to
Hi Rob!
On 2/28/22 19:18, John Paul Adrian Glaubitz wrote:
> 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).
On 2/28/22 19:18, John Paul Adrian Glaubitz wrote:
> The attached patch seems to work correctly. I had to escape the whole statements
> so that they are not interpreted by automake.
0 new messages