7 ms·
I would love to see the gc compiler support building dynamically linked executables against a libgo runtime Ala gccgo. Unless I'm misreading, this case doesn't
by axaxs 12y ago
I would love to see the gc compiler support building dynamically linked executables against a libgo runtime Ala gccgo. Unless I'm misreading, this case doesn't seem covered. I love the standalone binary deployment ease as of now, but on a machine with tens of go applications, the binary size redundancy gets old. Or did I miss something?
- FooBarWidget 12y agoWe're in an age where everybody is wasting gigabytes of memory through virtualization, and nobody cares. Would those few megabytes of memory saved by dynamically linking against libgo really be worth it? For past 5 years or so, it seems people value ease of deployment much more than efficiency.
- davidw 12y agoThe people who value their memory usage just aren't using that kind of system, so there's some selection bias there.
- ColinCera 12y agoYou have a point, but on mobile and embedded devices, nobody is "wasting gigabytes of memory through virtualization" and not caring.
- laumars 12y agoIt doesn't cost gigabytes of RAM, but Android applications do run on a Java virtual machine. But I'm being massively pedantic.
- peterbotond 12y agoyes. +1
- mrweasel 12y agoHow large are the binaries you deploy? Unless it's hundreds of MB per binary I does see the dynamically linked executables being worth the trouble. Of cause options are nice, I just worry that in the end I don't get to choose.
- ColinCera 12y agoI think one of the motivations is that they want Go to be a language suitable for Android development and other use cases. In mobile and embedded devices, binary size still matters.
- ianlancetaylor 12y agoI believe that use case is covered via -buildmode=shared and -linkshared. Just run -buildmode=shared when building the standard library.