Good idea.
FYI - this is on a Fedora 37 6.1.8-200.fc37.x86_64 server with go version
go1.20 linux/amd64.
I'm running a VM in Virtualbox with snapshots so it's very easy to go back
to an unmodified
system after running an experiment. Note that I'm adding the '-a' option to
the go build commands
so that go doesn't use cached versions of things.
The test program (t.go) is
package main
func main() {
}
Without having run go install -buildmode=shared std, go build -linkshared
-a t.go produces
/usr/local/go/pkg/tool/linux_amd64/link: cannot implicitly include
runtime/cgo in a shared library
I think this is a new error message. I didn't expect this command to
succeed but I was curious how it
would fail.
I then ran go install -buildmode=shared std which again ran without any
error messages.
Running go build -linkshared -a t.go now produces many error messages, all
complaining about
not being able to write to various subdirectories under
/usr/local/go/pkg/linux_amd64_dynlink.
Why running go build as a normal user results in writes to
/usr/local/go/pkg/linux_amd64_dynlink
is indeed a puzzlement.
To see whether the time difference problem still exists, I then changed the
ownership of
/usr/local/go/pkg/linux_amd64_dynlink to me. In ordinarily life I would
never do this but
this is in a test VM.
Now, running go build -linkshared -a t.go works! However, the slow build
time when building
with -sharedlink still exists.
% time go build -linkshared -a t.go
go build -linkshared -a t.go 43.57s user 6.09s system 262% cpu 18.928 total
% time go build -a t.go
go build -a t.go 4.26s user 0.53s system 174% cpu 2.750 total
This is slower than in my original report because I'm using the '-a' option
to eliminate any
benefit of the cache. Running without it is much faster but the relative
time difference
(e.g ~10x) still exists.
So, to answer your question, things don't appear to have changed with Go
1.20.
Cordially,
Jon Forrest
On Thursday, February 2, 2023 at 2:09:06 PM UTC-8 harald....@gmx.net wrote:
If I read the 1.20 release notes correctly, there has been a change with
how the compiled std lib not only is delivered (not anymore) and cached, so
that it now ends up in the module cache. Maybe you can retry your
experiments with 1.20 if this now works without the slightly ugly
workarounds?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/5397c8ef-3bd5-495f-89c9-c52ad7499470n%40googlegroups.com.
