[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-18 Thread ian at airs dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #22 from Ian Lance Taylor  ---
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.

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-18 Thread ian at airs dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #21 from Ian Lance Taylor  ---
*** Bug 103573 has been marked as a duplicate of this bug. ***

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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!

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #9

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
Patch #8

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #7

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #6

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #5

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #4

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #3

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
pathch #2

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread svante.signell at gmail dot com via Gcc-bugs
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=edit
patch #1

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:3f2a6b041d910cab08332ae01a8a9fcfe2e9036a

commit r12-7280-g3f2a6b041d910cab08332ae01a8a9fcfe2e9036a
Author: Ian Lance Taylor 
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

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-09 Thread svante.signell at gmail dot com via Gcc-bugs
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

2022-02-08 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #7 from Andreas Schwab  ---
If you make all-target-libgo all dependencies are respected.

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-08 Thread svante.signell at gmail dot com via Gcc-bugs
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

2022-02-08 Thread ian at airs dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #5 from Ian Lance Taylor  ---
> 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?

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-08 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

--- Comment #4 from Andreas Schwab  ---
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; };

[Bug go/104290] [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

2022-02-08 Thread svante.signell at gmail dot com via Gcc-bugs
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

2022-02-06 Thread svante.signell at gmail dot com via Gcc-bugs
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=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

2022-02-03 Thread svante.signell at gmail dot com via Gcc-bugs
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=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

2022-01-31 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0