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
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?
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
> 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
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
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
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
On 1/29/23, bobj...@gmail.com wrote:
> I'm glad to see this issue getting some discussion. I have 100+ smallish
> utility programs written in Go, and each one consumes about 1.5 MB (precise
>
> average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go
> runtime. Sadly, I mainly
Here are some more options you could consider.
1. Do what busybox does: put them all into separate packages, link them all
into one monster executable, switching on os.Args[0] to decide which main
function to run. Then add lots of links or symlinks to the same program so
it can be executed
Are the std/runtime .so's even versioned? How do you manage that?
Every time I'm feeling like finally being in $PARADISE out of the .so
dependency $VERYVERYHOTPLACE there comes along the demand to go back. Sigh.
;)
On Sunday, January 29, 2023 at 9:26:51 PM UTC+1 bobj...@gmail.com wrote:
>
I'm glad to see this issue getting some discussion. I have 100+ smallish
utility programs written in Go, and each one consumes about 1.5 MB (precise
average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go
runtime. Sadly, I mainly use Windows, and there seems to be no way to
The discussion of SSD wear and tear is going way off my original question.
I'm sorry I even mentioned it.
Can we drop it?
I'm still interested in the answer to the original question, which we've
made some progress in answering.
As of now the answer is yes, subject to some permission and
This is pretty OT, and I am no expert, but the overwhelming consensus on
the inter-tubes seems to be that *reading *from an SSD causes no 'wear'
whatsoever. It is only writes and deletes that age an SSD. So this use case
should not impact SSD life.
But it is an interesting endeavor on its
Shared dynamic libraries do reduce the “wear and tear” on an SSD. The binaries
are loaded a single time and shared across processes - slightly longer startup
times for the dynamic linkage.
It is highly beneficial with large runtimes vs small standard library usage in
tiny utilities.
> On
It does not surprise me that your shared run-time build takes more time
than the usual static build. The latter case is highly optimized while your
use case has probably been given very little consideration. I am also
confused by your argument for supporting linking against a shared Go
runtime
Thanks for the reply. I had mixed results.
On Fedora 37, go version go1.19.4 linux/amd64, in /usr/local/go/src as root
I ran
go install -buildmode=shared std
That seemed to work.
In my normal working directory, as me, not root, I ran
go build -linkshared *.go
(I do a regular build in this
On Sat, Jan 28, 2023 at 11:27 AM jlfo...@berkeley.edu
wrote:
>
> For people like me who have no intention of ever distributing a Go
> executable, I wonder
> if it would be useful, and possible, to link to a shared library version of
> the Go
> Runtime. This would make my binaries much smaller
For people like me who have no intention of ever distributing a Go
executable, I wonder
if it would be useful, and possible, to link to a shared library version of
the Go
Runtime. This would make my binaries much smaller and would reduce ware and
tear on my SSD.
Of course, this presumes that
18 matches
Mail list logo
