NetBSD Problem Report #58830

From dholland@netbsd.org  Mon Nov 18 05:17:23 2024
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id BAD771A9238
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 18 Nov 2024 05:17:23 +0000 (UTC)
Message-Id: <20241118051723.0CF6E8558F@mail.netbsd.org>
Date: Mon, 18 Nov 2024 05:17:23 +0000 (UTC)
From: dholland@NetBSD.org
Reply-To: dholland@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: WRKDIR references in go123 
X-Send-Pr-Version: 3.95

>Number:         58830
>Category:       pkg
>Synopsis:       WRKDIR references in go123
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    bsiegert
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 18 05:20:00 +0000 2024
>Closed-Date:    
>Last-Modified:  Fri Sep 11 07:30:01 +0000 2026
>Originator:     David A. Holland
>Release:        NetBSD 10.99.10 (20240218), pkgsrc 20241118
>Organization:
Windmill Containment Office
>Environment:
System: NetBSD valkyrie 10.99.10 NetBSD 10.99.10 (VALKYRIE2) #0: Mon Feb 19 02:27:48 EST 2024  dholland@valkyrie:/y/objects/usrobj/sys/arch/amd64/compile/VALKYRIE2 amd64
Architecture: x86_64
Machine: amd64
>Description:

valkyrie% strings `which go123` | grep /usr/pkgsrc/lang/go123/work/ | wc -l
     954

This should not be the case. Also, trying to build pkglint with it
fails because it thinks its GOROOT is /usr/pkgsrc/lang/go123/work/go,
so I think it basically just isn't working.

Doesn't happen with a freshly built go122.

>How-To-Repeat:

make install

>Fix:

Dunno.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->bsiegert
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Mon, 18 Nov 2024 07:44:11 +0000
Responsible-Changed-Why:
Over to the go master


From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/58830 (WRKDIR references in go123)
Date: Mon, 18 Nov 2024 14:34:18 +0100

 Yes, this is a known issue. The go tool needs to know its executable
 path so it can find the standard library files. It calls
 os.Executable(), which uses /proc on NetBSD.

 I sent a change upstream
 (https://go-review.googlesource.com/c/go/+/629035) to make it use
 sysctl instead, like on FreeBSD and Dragonfly. We are shortly before
 the Go 1.24 freeze, I hope it can still go in.

 -- 
 Benny

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: bsiegert@netbsd.org
Subject: Re: pkg/58830 (WRKDIR references in go123)
Date: Tue, 19 Nov 2024 04:12:50 +0000

 On Mon, Nov 18, 2024 at 01:35:01PM +0000, Benny Siegert via gnats wrote:
  >  Yes, this is a known issue. The go tool needs to know its executable
  >  path so it can find the standard library files. It calls
  >  os.Executable(), which uses /proc on NetBSD.
  >  
  >  I sent a change upstream
  >  (https://go-review.googlesource.com/c/go/+/629035) to make it use
  >  sysctl instead, like on FreeBSD and Dragonfly. We are shortly before
  >  the Go 1.24 freeze, I hope it can still go in.

 That sounds great, but I don't immediately understand how that's
 related to WRKDIR references.

 There's a patch that says
    Build with debugging symbols and paths built in. Otherwise, the go tool
    needs /proc mounted to find its goroot directory.
 but go122 has the same patch and doesn't end up with WRKDIR references.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Benny Siegert <bsiegert@netbsd.org>
To: David Holland <dholland-pbugs@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: pkg/58830 (WRKDIR references in go123)
Date: Tue, 19 Nov 2024 11:49:27 +0100

 On Tue, Nov 19, 2024 at 5:12=E2=80=AFAM David Holland <dholland-pbugs@netbs=
 d.org> wrote:

 > That sounds great, but I don't immediately understand how that's
 > related to WRKDIR references.
 >
 > There's a patch that says
 >    Build with debugging symbols and paths built in. Otherwise, the go too=
 l
 >    needs /proc mounted to find its goroot directory.
 > but go122 has the same patch and doesn't end up with WRKDIR references.

 The reason that this changed is that the "old" way -- baking in
 GOROOT_FINAL into the binaries -- was removed in Go 1.23.

 For Go 1.24, my patch was accepted, and it will use sysctl
 (kern.proc.args.-1.pathname) to find the standard library files. If
 you would like, I could backport this patch to Go 1.23 in pkgsrc.

 --=20
 Benny

State-Changed-From-To: open->feedback
State-Changed-By: bsiegert@NetBSD.org
State-Changed-When: Thu, 02 Jan 2025 20:31:47 +0000
State-Changed-Why:
Can you please check if this is still an issue
with go123-1.23.4nb1?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 03 Jan 2025 00:29:33 +0000
State-Changed-Why:
Alas, that fixed the GOROOT problem (so the compiler runs) but it is
still full of WRKDIR :-(


From: Kimmo Suominen <kim@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/58830 (WRKDIR references in go123)
Date: Fri, 3 Jan 2025 08:56:48 +0200

 The go binary has 954 references to WRKDIR, which are not caught by pkgsrc:

     :...pkg/go123> strings bin/go | fgrep /tmp/kim/pkgsrc/ | wc -l
          954

 For comparison, previous versions do not have these references:

     :...pkg/go120> strings bin/go | fgrep /tmp/kim/pkgsrc/ | wc -l
            0

     :...pkg/go118> strings bin/go | fgrep /tmp/kim/pkgsrc/ | wc -l
            0

     :...pkg/go14> strings bin/go | fgrep /tmp/kim/pkgsrc/ | wc -l
            0

From: Benny Siegert <bsiegert@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/58830
Date: Fri, 11 Sep 2026 07:28:20 +0000 (UTC)

 I analyzed this more, with the go127 binary.

 There is indeed one mention of the workdir in .rodata, I don't know why it 
 is there.

 But other than that, all the mantions of the work directory are in the 
 .gopclntab section, which is mandatory and cannot be removed. The purpose 
 of the file names recorded there is to be used in stack traces. If you 
 make the go tool panic, it will give you a file name and line number, 
 including the original work dir. IMHO, that's totally harmless.

 Any other binary built from the Go toolchain will also include the full 
 path of every source file.

 I am inclined to close this as "working as intended".

 -- 
 Benny

>Unformatted:

Home	PR Database Search