Re: Building lang/go* and go ports broken on main (amd64)?

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sun, 01 Jun 2025 06:06:32 UTC
On Sat, May 31, 2025 at 10:05:16PM -0700, Cy Schubert wrote:
> In message <20250601041116.0A5642A9@slippy.cwsent.com>, Cy Schubert writes:
> > In message <aDoAwUn7jGs7Ycjq@kib.kiev.ua>, Konstantin Belousov writes:
> > > On Fri, May 30, 2025 at 04:14:44PM +0200, Herbert J. Skuhra wrote:
> > > > On Fri, 30 May 2025 13:32:27 +0200, Konstantin Belousov wrote:
> > > > > 
> > > > > On Fri, May 30, 2025 at 09:36:39AM +0200, Herbert J. Skuhra wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > building lang/go (e.g. 1.24) and go ports (e.g. aerc, netbird) on mai
> > n
> > > > > > (amd64) fails with: fatal: bad g in signal handler. 
> > > > > > Arm64 seems to be OK.
> > > > > 
> > > > > I might have a guess.  Try the following untested patch, you need to re
> > bu
> > > ild
> > > > > at least kernel, but ideally both kernel and userspace.  Also it is amd
> > 64
> > > -only.
> > > > 
> > > > Thanks a lot! With your patch I could build go 1.24 and netbird again.
> > >
> > > Is there any go code that uses cgo, and which you could test with the patch
> > > as well?
> > >
> >
> > It's a bad system call. Yesterday's buildworld/installworld made the system 
> > unable to run today's installworld.
> >
> > --- installworld ---
> > make[1]: /export/obj/opt/src/git-src/amd64.amd64/toolchain-metadata.mk:1: 
> > Using cached toolchain metadata from build at stinky on Sat May 31 20:16:05 
> > PDT 2025
> > --- __installcheck_UGID ---
> > --- __installcheck_sh_check ---
> > Bad system call (core dumped)
> > rescue/sh check failed, installation aborted
> >
> > make[1]: stopped making "installworld" in /opt/src/git-src
> >
> > make: stopped making "installworld installkernel" in /opt/src/git-src
> >
> > The go problem is likely related to this.
> 
> The resolution is:
> 
> git pull the latest 15-CURRENT. Buildkernel and installkernel. Then 
> buildworld and installworld. Remember to rebuild drm-66-kmod or it will 
> panic. Any Go software will build correctly.

In fact, I am not completely sure about Go.
Pure Go binaries should work.

The interesting case is cgo binaries, which start libpthread threads.
I am interested if they work, and if no, I have some ugly trick to apply.