trunk 20220126 fails to build libgo on i686-gnu: ../../../src/libgo/go/net/unixsock_posix.go:116:56: error: reference to undefined name 'readMsgFlags' 116 | n, oobn, flags, sa, err = c.fd.readMsg(b, oob, readMsgFlags) | ^ ../../../src/libgo/go/net/unixsock_posix.go:117:12: error: reference to undefined name 'readMsgFlags' 117 | if readMsgFlags == 0 && err == nil && oobn > 0 { | ^ ../../../src/libgo/go/net/unixsock_posix.go:118:17: error: reference to undefined name 'setReadMsgCloseOnExec' 118 | setReadMsgCloseOnExec(oob[:oobn]) | ^ Makefile:3026: recipe for target 'net.lo' failed make[6]: *** [net.lo] Error 1
Created attachment 52345 [details] 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!
Created attachment 52360 [details] 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!
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 passes 181 # of unexpected failures 9 Thanks!
Makefile.def already has the required dependencies: dependencies = { module=all-target-libgo; on=all-target-libbacktrace; }; dependencies = { module=all-target-libgo; on=all-target-libffi; }; dependencies = { module=all-target-libgo; on=all-target-libatomic; };
> The only issue to resolve is how to make sure libatomic and libbacktrace builds in build/i686-gnu before libgo/gotools. That question doesn't sound right. The gotools are built for the target. They shouldn't depend on build/i686-gnu, which is built for the host. The gotools should depend on the target libatomic and the target libbacktrace, and they do. What problem are you trying to solve?
OK, forget about the gotools. The problem is that libgo is built _before_ libatomic and libbacktrace. A Debian error??
If you make all-target-libgo all dependencies are respected.
> 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!
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>: https://gcc.gnu.org/g:3f2a6b041d910cab08332ae01a8a9fcfe2e9036a commit r12-7280-g3f2a6b041d910cab08332ae01a8a9fcfe2e9036a Author: Ian Lance Taylor <iant@golang.org> Date: Wed Feb 16 16:57:28 2022 -0800 net: add hurd build tag for setReadMsgCloseOnExec Patch from Svante Signell. PR go/103573 PR go/104290 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/386216
Created attachment 52464 [details] patch #1
Created attachment 52465 [details] pathch #2
Created attachment 52466 [details] patch #3
Created attachment 52467 [details] patch #4
Created attachment 52468 [details] patch #5
Created attachment 52469 [details] patch #6
Created attachment 52470 [details] patch #7
Created attachment 52471 [details] Patch #8
Created attachment 52472 [details] patch #9
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 103573 has been marked as a duplicate of this bug. ***
Thanks. I'll commit your patches #1 through #8. Your patch #9 is to a generated file. The fix there can't be to patch just the top-level Makefile.in. It has to be to patch whatever is causing Makefile.in to be generated the way that it is. I don't myself know what is going wrong there.
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>: https://gcc.gnu.org/g:3343e7e2c4cd2cd111cda86737f539cc6eda49ff commit r12-7298-g3343e7e2c4cd2cd111cda86737f539cc6eda49ff Author: Ian Lance Taylor <iant@golang.org> Date: Fri Feb 18 15:04:00 2022 -0800 libgo: update Hurd support Patches from Svante Signell for PR go/104290. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/386797
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!
> 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. > 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 I don't understand why that patch makes any difference. Where is the code that checks OPTION_GLIBC?
(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!
Thanks for the explanation. Sounds like you should send the config/gnu.h patch to the x86 maintainers (and CC gcc-patches).
GCC 12.1 is being released, retargeting bugs to GCC 12.2.
What's the status here on the GCC 12 branch and trunk?
I suspect the libbacktrace issue is an issue with building in the source.
GCC 12.2 is being released, retargeting bugs to GCC 12.3.
What's the status?
As far as I know nothing is waiting on me. Please let me know if you think otherwise.
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!
GCC 12.3 is being released, retargeting bugs to GCC 12.4.