[Bug go/93020] New: Final patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020 Bug ID: 93020 Summary: Final patches to build gcc-10 on GNU/Hurd Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: svante.signell at gmail dot com CC: cmang at google dot com Target Milestone: --- Created attachment 47529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47529&action=edit Fixes FTBFS for gcc-10 on GNU/Hurd Hello, Test-compiling Debian Version gcc-10-10-20191217-1 reveals that two small fixes are still needed for a successful build, one in runtime/os_hurd.go and one in poll/errno_unix.go. The attached patch hurd.diff fixes that. Thanks!
[Bug go/93020] Final patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020 --- Comment #2 from Svante Signell --- Created attachment 47531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47531&action=edit Fixes libgo syscall test
[Bug go/93020] Final patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020 --- Comment #1 from Svante Signell --- Created attachment 47530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47530&action=edit Fixes libgo os test.
[Bug other/93049] New: limits.h generated by fixincludes breaks cross-compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049 Bug ID: 93049 Summary: limits.h generated by fixincludes breaks cross-compilation Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: svante.signell at gmail dot com Target Milestone: --- Created attachment 47542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47542&action=edit fix for glimits.h Hello, Cross-compiling from x86_64-linux-gnu to i686-gnu breaks for example the builds of sed-4.7 and coreutils-8.31, as well as Linux-PAM-1.3.1. The first two failures are due to that the fixed limits.h #define MB_LEN_MAX 1 while the system one has #define MB_LEN_MAX 16. The third error is due to that #ifdef __USE_POSIX2 # include #endif is chopped off the generated limits.h, leaving LINE_MAX undefined. The problem seems to be in the file gcc-9.2.0/gcc/glimits.h causing the generated gcc-9.2.0.obj/gcc/include-fixed/limits.h. The attached patch fixinc_glimits.h.diff fixes that problem.
[Bug go/93468] New: New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 Bug ID: 93468 Summary: New patches to build gcc-10 on GNU/Hurd Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: svante.signell at gmail dot com CC: cmang at google dot com Target Milestone: --- Created attachment 47718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47718&action=edit netpoll_hurd.go update Fixes FTBFS for gcc-snapshot-20200124 on GNU/Hurd Hello, Test-compiling Debian Version gcc-10-10-20200124-1 reveals that three small fixes are needed for a successful build, one in runtime/netpoll_hurd.go, one in syscall/sockcmsg_unix_other.go and one in runtime/nbpipe_pipe2.go. The attached patches fixes the build and tests of libgo. There are still two tests failing due to linkage problems. When time permits I'll investigate these problems. Thanks!
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #1 from Svante Signell --- Created attachment 47719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47719&action=edit Add hurd to // +build
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #2 from Svante Signell --- Created attachment 47720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47720&action=edit Add hurd to // +build
[Bug go/93468] New patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93468 --- Comment #3 from Svante Signell --- ping! These patches are very minor. What takes so long time? They were reported for gcc-10, I did not find any entry for gcc-snapshot. Is gcc-10 released and stable, compared to gcc-snapshot, i.e. current master/? Thanks!
[Bug go/93900] New: Patches to fix build of gcc-10-10-20200222 for GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93900 Bug ID: 93900 Summary: Patches to fix build of gcc-10-10-20200222 for GNU/Hurd Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: svante.signell at gmail dot com CC: cmang at google dot com Target Milestone: --- Created attachment 47894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47894&action=edit Add hurd to // +build Hello, The latest Debian version of gcc-10 (10-20200222) FTBFS on GNU/Hurd. The attached patches fixes this problem. Thanks!
[Bug go/93900] Patches to fix build of gcc-10-10-20200222 for GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93900 --- Comment #1 from Svante Signell --- Created attachment 47895 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47895&action=edit Add hurd to // +build
[Bug go/93900] Patches to fix build of gcc-10-10-20200222 for GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93900 --- Comment #4 from Svante Signell --- Sorry, but there were two patches attached: one for libgo/go/internal/syscall/unix/nonblocking.go and one for libgo/go/internal/poll/fcntl_syscall.go >From the commit https://gcc.gnu.org/g:027a3f1c38727a1ea0969088b0680b2f6bb1e977 it seem like the second one was not applied.
[Bug tree-optimization/84817] New: PR tree-optimization/84526: gcc-8-8-20180310-1 FTBFS on GNU/Hurd by removing "dead" code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84817
Bug ID: 84817
Summary: PR tree-optimization/84526: gcc-8-8-20180310-1 FTBFS
on GNU/Hurd by removing "dead" code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: svante.signell at gmail dot com
Target Milestone: ---
Hi,
Latest Debian version of gcc-8: gcc-8-8-20180310-1 (r258410) FTBFS due to
gimple-match.c problems:
build/genmatch --gimple ../../src/gcc/match.pd \
> tmp-gimple-match.c
GIMPLE decision tree has 2511 leafs, maximum depth 12 and a total number of
9849 nodes
removed 1569 duplicate tails
build/genmatch --generic ../../src/gcc/match.pd \
> tmp-generic-match.c
GENERIC decision tree has 2461 leafs, maximum depth 12 and a total number of
9612 nodes
removed 1530 duplicate tails
/bin/bash ../../src/gcc/../move-if-change tmp-gimple-match.c \
gimple-match.c
/bin/bash ../../src/gcc/../move-if-change tmp-generic-match.c \
generic-match.c
echo timestamp > s-match
/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/./prev-gcc/xg++
-B/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/./prev-gcc/
-B/usr/i686-gnu/bin/ -nostdinc++
-B/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/src/.libs
-B/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/libsupc++/.libs
-I/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/include/i686-gnu
-I/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/include
-I/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/src/libstdc++-v3/libsupc++
-L/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/src/.libs
-L/home/srs/DEBs/gcc-8/gcc-8-8-20180310-1.1/build/prev-i686-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wno-unused
-DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/.
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid
-I../libdecnumber -I../../src/gcc/../libbacktrace -o gimple-match.o -MT
gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo gimple-match.c
gimple-match.c: In function 'bool gimple_simplify_FLOAT_EXPR(code_helper*,
tree_node**, gimple**, tree_node* (*)(tree), code_helper, tree, tree)':
gimple-match.c:15146:1: error: unable to find a register to spill
}
^
gimple-match.c:15146:1: error: this is the insn:
(insn 616 3197 2728 97 (parallel [
(set (reg:DI 938 [547])
(ashift:DI (reg:DI 938 [547])
(reg:QI 1367)))
(clobber (reg:CC 17 flags))
]) "../../src/gcc/hwint.h":293 431 {*ashldi3_doubleword}
(expr_list:REG_DEAD (reg:QI 1367)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
gimple-match.c:15146: confused by earlier errors, bailing out
Looking at src/gcc/Changelog one finds:
2018-03-09 Martin Sebor
PR tree-optimization/84526
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Remove dead code.
Replacing the file src/gcc/gimple-ssa-warn-restrict.c with an older version of
that file from gcc-8: gcc-8-8-20180308-1 (r258348) makes the build successful
again.
Can you please revert the changes that breaks the build?
Thanks!
[Bug tree-optimization/84817] gcc-8-8-20180310-1 FTBFS on GNU/Hurd due to commit: PR target/83712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84817 Svante Signell changed: What|Removed |Added Summary|PR tree-optimization/84526: |gcc-8-8-20180310-1 FTBFS on |gcc-8-8-20180310-1 FTBFS on |GNU/Hurd due to commit: PR |GNU/Hurd by removing "dead" |target/83712 |code| --- Comment #2 from Svante Signell --- Hello, It seem like the changed file did not make the build to complete. However, I found the revert patch you referred to: gcc.git-b12c2c48c2c6aa1db9e6c50f6b26330d9caf.patch and applied it to gcc-8-8-20180310-1, and the build completed. I did also build gcc-8-8-20180312-2 and that went fine too. So you can close this bug now. Thanks!
[Bug tree-optimization/84817] gcc-8-8-20180310-1 FTBFS on GNU/Hurd due to commit: PR target/83712
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84817 Svante Signell changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug lto/60571] New: FTBFS on hurd-i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60571 Bug ID: 60571 Summary: FTBFS on hurd-i386 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: svante.signell at gmail dot com Created attachment 32384 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32384&action=edit Use WCONTINUED as third argument to waitpid only if defined Hi, Currently gcc-4.9 (20140218-1 20140303-1) and fails to build on GNU/Hurd due to WCONTINUED not being defined. The attached patch solves this problem by only using that option as third argument to waitpid when available. This flag is Linux-specific, and according to the Linux waitpid man page it was introduced in 2.6.10. Reported as Debian bug #740153 and accepted to be part of next gcc-4.9 snapshot. Thanks!
[Bug c/63448] New: ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 Bug ID: 63448 Summary: ICE when compiling atlas 3.10.2 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: svante.signell at gmail dot com
[Bug c/63448] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #1 from Svante Signell --- Created attachment 33642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33642&action=edit Preprocessed source stored into /tmp/ccejGHdk.out file
[Bug c/63448] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #2 from Svante Signell --- Hi, when compiling ./build/atlas-base/src/blas/gemm/KERNEL/ATL_cNCCUmmNN.c from Debian atlas 3.10.2-3 on GNU/Hurd the ICE happens (twice): ATL_cNCCUmmNN.c:3856:1: internal compiler error: Maximum number of LRA constraint passes is achieved (30) } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. gcc version is Debian 4.9.1-15. It might be so that the input data for this generated file is non-sensical, the CPU speed detection does not work on Hurd. Nevertheless, the compiler should not error out with an ICE? Thanks!
[Bug c/63448] ICE when compiling atlas 3.10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448 --- Comment #5 from Svante Signell --- FYI: atlas builds fine with gcc-4.8.3-11 (and gfortran-4.9-15)
[Bug go/98153] [11 Regression] libgo ftbfs on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98153 --- Comment #1 from Svante Signell --- Created attachment 49702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49702&action=edit Build fix of libgo for GNU/Hurd
[Bug go/98153] [11 Regression] libgo ftbfs on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98153 --- Comment #2 from Svante Signell --- Hello, Looking into the build failure of libgo for GNU/Hurd reveals that since AF_LINK is not yet supported, the corresponding code for SockaddrDatalink stuff needs to be stripped off socket_bsd.go, thereby creating socket_hurd.go. This is reflected in the attached patch. Thanks!
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #3 from Svante Signell --- On Sat, 2021-01-02 at 17:49 +, doko at debian dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 > > Matthias Klose changed: > >What|Removed |Added > --- > - > Status|RESOLVED|UNCONFIRMED > Resolution|FIXED |--- > > --- Comment #2 from Matthias Klose --- > now fails with: > > ../../../src/libgo/go/crypto/x509/root_unix.go:52:17: error: > reference to > undefined name 'certDirectories' >52 | dirs := certDirectories > | ^ I'm onto it. Patch will follow soon. A simple fix if this is the only issue. Thanks!
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #4 from Svante Signell --- Created attachment 49930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49930&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #5 from Svante Signell --- Created attachment 49931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49931&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #6 from Svante Signell --- Created attachment 49932 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49932&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #7 from Svante Signell --- Created attachment 49933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49933&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #8 from Svante Signell --- Created attachment 49934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49934&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #9 from Svante Signell --- Created attachment 49935 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49935&action=edit gcc-11 patches for libgo
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #10 from Svante Signell --- Hello, The 6 attached patches are improving the build and tests of gccgo for Hurd. Attachment 49931 is needed for libgo to build, while the other are improving the tests of libgo,go and gotools. Attachment 49934 if just a cosmetic change of os_hurd.go. Further changes are still needed to the Makefiles of libgo and gotools to enable proper linking of libpthread and libdl. The dynamic linking of extra libraries does not work automatically as it does on Linux systems. Thanks!
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #11 from Svante Signell --- ping?
[Bug go/104290] [12/13 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #34 from Svante Signell --- This is incredible. Now Debian forgot to add the spilt-stack patch for GNU/Hurd for gcc-13 (1:20230315-1). But it shouldn't be needed, it should have been upstreamed a long time ago. The patch is from January 2022! PS: I don't know how to change the title of this regression, it should now read: [12/13 Regression] trunk 20230315 fails to build libgo on i686-gnu Thank you for your attention!
[Bug go/104290] [12 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #24 from Svante Signell --- Thanks Ian, Hopefully someone knows hot to modify Makefile.tpl/Makefile.def to generate the correct dependencies in Makefile.in. Another patch that is not applied: gcc_config_gnu.h.diff. Who will commit that patch? It is not directly relating to libgo, but gotools fails to build later on without it. Thanks!
[Bug go/104290] [12 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290
--- Comment #26 from Svante Signell ---
(In reply to Ian Lance Taylor from comment #25)
> > Hopefully someone knows hot to modify Makefile.tpl/Makefile.def to generate
> > the correct dependencies in Makefile.in.
>
> I suggest that you open a separate bug for that, with a complete standalone
> explanation of the problem. This bug is mixed in with a lot of other things.
OK, will do.
> > Another patch that is not applied: gcc_config_gnu.h.diff. Who will commit
> > that patch? It is not directly relating to libgo, but gotools fails to
> > build later on without it.
>
> I assume you mean this patch:
>
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52360&action=edit
Yes!
> I don't understand why that patch makes any difference. Where is the code
> that checks OPTION_GLIBC?
Pasted from Comment 1 and Comment 2:
start paste__
Additionally, continuing, the build of gotools fails:
go1: error: '-fsplit-stack' currently only supported on GNU/Linux
go1: error: '-fsplit-stack' is not supported by this compiler configuration
The attached patch defines OPTION_GLIBC_P and OPTION_GLIBC that was lost for
config/gnu.h, thus enabling split-stack support for GNU/Hurd again.
This problem happened with the latest commit and fixes for #104170 and as
discussed in the mail thread starting with
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588973.html.
end paste___
The file first doing this check is: (first error: ..)
src/gcc/common/config/i386/i386-common.cc
in function:
static bool ix86_supports_split_stack (bool report,
struct gcc_options *opts ATTRIBUTE_UNUSED)
and secondly in:src/gcc/opts.cc: (second error: ...)
in function:
void
finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
location_t loc)
The checking logic is in function ix86_supports_split_stack():
#if defined(TARGET_THREAD_SPLIT_STACK_OFFSET) && defined(OPTION_GLIBC_P)
if (!OPTION_GLIBC_P (opts))
#endif
{
if (report)
error ("%<-fsplit-stack%> currently only supported on GNU/Linux");
return false;
}
bool ret = true;
In case of GNU/Hurd TARGET_THREAD_SPLIT_STACK_OFFSET is defined as well as
OPTION_GLIBC_P but OPTION_GLIBC_P (opts) is needed to. The proposed patch to
src/gcc/config/gnu.h creates that definition. Additionally, gnu.h is included
in the configure stage:
Configuring stage 1 in ./gcc
...
Using the following target machine macro files:
...
../../src/gcc/config/gnu.h
Thanks!
[Bug regression/104660] New: Makefile.in has embedded dependencies of libatomic and libbacktrace for libgo, causing GNU/Hurd build to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104660 Bug ID: 104660 Summary: Makefile.in has embedded dependencies of libatomic and libbacktrace for libgo, causing GNU/Hurd build to fail. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: svante.signell at gmail dot com Target Milestone: --- Created attachment 52497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52497&action=edit Patch of src/Makefile.in Hello, The generated file Makefile.in has embedded dependencies on libatomic and libbacktrace preventing them to be built before libgo: The dependency of libffi: all-target-libgo: maybe-all-target-libffi is outside any conditionals but libbacktrace and libatomic is not: @unless gcc-bootstrap ... all-target-libgo: maybe-all-target-libbacktrace all-target-libgo: maybe-all-target-libatomic ... @endunless gcc-bootstrap Due to this condition the generated build/Makefile does not contain the dependencies on libatomic and libbacktrace, causing the build to fail on GNU/Hurd. Generating a new version of Makefile.in by: (cd source; autogen Makefile.def) does not solve the problem: the same buggy build/Makefile is created. Attached is a patch to move the dependencies outside of the conditional. However, since Makefile.in is generated the problem lies in Makefile.def/Makefile.tpl. Unfortunately not much is documented on this conditional pair: @unless, @endunless Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 Svante Signell changed: What|Removed |Added CC||svante.signell at gmail dot com --- Comment #1 from Svante Signell --- Created attachment 52345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52345&action=edit Adding hurd to unixsock_readmsg_cloexec.go fixes the build of libgo Hello, The attached patch fixes the build of libgo for GNU/Hurd for gcc-12-20220126 when patching the generated libgo/Makefile as follows: change ../libbacktrace/libbacktrace.la to ../../libbacktrace/libbacktrace.la and remove libatomic from the linkage: LIBATOMIC = ../libatomic/libatomic_convenience.la PTHREAD_CFLAGS = -pthread -L../libatomic/.libs since libatomic is not built yet. It should built before libgo but does not. Unknown why, it may be a problem with the Debian stuff. Additionally, continuing, the build of gotools fails: go1: error: '-fsplit-stack' currently only supported on GNU/Linux go1: error: '-fsplit-stack' is not supported by this compiler configuration The reason for this also unknown so far, libgo and gotools built fine with split-stack on gcc-11. Is this problem related to that libatomic not yet has bee built?? Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #2 from Svante Signell --- Created attachment 52360 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52360&action=edit Fix broken split-stack support for GNU/Hurd Hello, The attached patch defines OPTION_GLIBC_P and OPTION_GLIBC that was lost for config/gnu.h, thus enabling split-stack support for GNU/Hurd again. This problem happened with the latest commit and fixes for #104170 and as discussed in the mail thread starting with https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588973.html. I'll submit both patches in this bug report to gcc-patches soon, if nobody takes this problem up here. I still need to find out why libgo is built before libatomic and why libbacktrace is not found where excpected. Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #3 from Svante Signell --- With the proposed patches everything builds fine. The only issue to resolve is how to make sure libatomic and libbacktrace builds in build/i686-gnu before libgo/gotools. Any ideas? I'm not sure if this is a Debian or upstream problem. After a failed build I did: make -C build configure-target-libatomic make -C build/i686-gnu/libatomic/ make -C build configure-target-libbacktrace make -C build/i686-gnu/libbacktrace/ debian/rules build fakeroot debian/rules binary All debs built fine. Additionally make -C build/i686-gnu/libgo check reports in build/i686-gnu/libgo/libgo.sum === libgo Summary === # of expected passes181 # of unexpected failures9 Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #6 from Svante Signell --- OK, forget about the gotools. The problem is that libgo is built _before_ libatomic and libbacktrace. A Debian error??
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #8 from Svante Signell --- > If you make all-target-libgo all dependencies are respected. Sorry but that is not how things work: all-target-libgo: maybe-all-target-libffi is outside any conditionals, but all-target-libgo: maybe-all-target-libbacktrace all-target-libgo: maybe-all-target-libatomic are inside the conditional @unless gcc-bootstrap @endunless gcc-bootstrap in src/Makefile.in :( and therefore not included in the generated build/Makefile. The unless/endunless condition does not seem to be met in the generated build/Makefile. As far as I've searched, no understandable explanation of @unless/@endunless gcc-bootstrap is found in the gcc-12 tree either. No explanation in Makefile.tpl I found only a commit for binutils-gdb: https://isrc.iscas.ac.cn/gitlab/mirrors/sourceware.org/git_binutils-gdb/-/commit/4119873a48042e532f7485b84cca83ea0bf1fcf6 but that one is not very informative :( moving all-target-libgo: maybe-all-target-libbacktrace all-target-libgo: maybe-all-target-libatomic next to all-target-libgo: maybe-all-target-libffi in Makefile.in all works fine. Generating a new version of Makefile.in by: (cd source; autogen Makefile.def) does not solve the problem: the same buggy build/Makefile is created. This is not a Debian problem, it is an upstream bug, as far as I've found. It seems like everything not linux-any is left unsupported, not a nice situation... Your choice! And patching gnu.h to not support split-stack any longer is really not nice. Don't you ever build gcc for GNU/Hurd? If not maybe I can help to set up such a build environment. Just let me know!! Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #10 from Svante Signell --- Created attachment 52464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52464&action=edit patch #1
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #11 from Svante Signell --- Created attachment 52465 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52465&action=edit pathch #2
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #12 from Svante Signell --- Created attachment 52466 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52466&action=edit patch #3
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #13 from Svante Signell --- Created attachment 52467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52467&action=edit patch #4
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #14 from Svante Signell --- Created attachment 52468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52468&action=edit patch #5
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #15 from Svante Signell --- Created attachment 52469 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52469&action=edit patch #6
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #16 from Svante Signell --- Created attachment 52470 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52470&action=edit patch #7
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #17 from Svante Signell --- Created attachment 52471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52471&action=edit Patch #8
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #18 from Svante Signell --- Created attachment 52472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52472&action=edit patch #9
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #19 from Svante Signell --- Hi again, Attached are patch #1 to patch #9 to make libgo.so.21.0.0 to build successfully, from the source gcc-12-12-20220214. I see that the first patch: "Adding hurd to unixsock_readmsg_cloexec.go" was committed upstream today by Ian. Thanks! Now remains the patch "Fix broken split-stack support for GNU/Hurd" plus patch #1 to patch #9 to be upstreamed. patch #9 patches Makefile.in to ensure that libbacktrace and libatomic are built before libgo as explained in an earlier posting. BTW: This bug should be retitled to: [12 Regression] trunk 20220214 fails to build libgo on i686-gnu Dunno however how to change it. And posting here does not result in an email to me, how come? Fortunately the comments from other people results in an email. Thanks!
[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #20 from Svante Signell --- Hi again, Attached are patch #1 to patch #9 to make libgo.so.21.0.0 to build successfully, from the source gcc-12-12-20220214. I see that the first patch: "Adding hurd to unixsock_readmsg_cloexec.go" was committed upstream today by Ian. Thanks! Now remains the patch "Fix broken split-stack support for GNU/Hurd" plus patch #1 to patch #9 to be upstreamed. patch #9 patches Makefile.in to ensure that libbacktrace and libatomic are built before libgo as explained in an earlier posting. BTW: This bug should be retitled to: [12 Regression] trunk 20220214 fails to build libgo on i686-gnu Dunno however how to change it. And posting here does not result in an email to me, how come? Fortunately the comments from other people results in an email. Thanks!
