Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-02-03 Thread jlfo...@berkeley.edu
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

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-02-02 Thread TheDiveO
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?

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-01-31 Thread jlfo...@berkeley.edu
I agree with you 100%. The 'go install' step that creates the shared runtime library should only be done by root. On the other hand, there's no reason I can see for the 'go build' step to write anything at all into /usr/local/go. But that's clearly happening. That's one of the causes of this

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-01-31 Thread TheDiveO
> So, the solution to problem #1 is to make sure a normal user can create /usr/local/go/pkg/linux_amd64_dynlink and files in and underneath it. While this is fine as a proof of concept and to diagnose the situation, I don't think that it can be called good advice to make /usr/local writeable to

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-01-30 Thread jlfo...@berkeley.edu
Thanks for the comments. I had to do it as root because running go install -buildmode=shared std as me results in go install internal/goarch: mkdir /usr/local/go/pkg/linux_amd64_dynlink: permission denied As root, changing the ownership of /usr/local/go/pkg/linux_amd64_dynlink to me, and

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-01-30 Thread Jim Idle
Looking back at your posts, I think you got there because your initial build of the shared library was via sudo? I don’t think that was correct and you didn’t need sudo. If the shared library only contained code needed for your executable, then it could only be shared by other instances of your

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

2023-01-30 Thread jlfo...@berkeley.edu
I'm the original poster. I've looked into this more and I might have an explanation for what's going on. Just for yuks, I started with perhaps the simplest Go program, which I called t.go: package main func main() { } As root, I was able to build both a dynamically (21512 bytes) and a