Please provide a minimal, self contained demonstration code that reproduces the problem. Then it should be hopefully easy to either explain why things work they do or it'll be a nice test case for the fix to the issue this may actually be. Thanks.
On Fri, Jun 28, 2019, 20:10 <luka.ve...@gmail.com> wrote: > I have come up against something a bit strange and interesting that I > didn't really expect from the Go compiler. > > I have a main which uses a structure created in a package, which contains > a whole load of references to other packages. > > What I discovered is that even though only one of these included packages > is used, the whole set still gets included in the binary. > > Am I right in saying that packages create a linker object file, as a > whole, and every package imported is also linked? > > In the case of my application it means I now have to manually break up a > whole load of nice pretty neat declarations into pieces that return > generator functions, and each part has to come from a different package, > meaning a folder and one tiny little source file. > > I couldn't find any reasonable terms that explained Go's linking > mechanisms but it dawned on me as I thought about how each folder in the > tree creates a binary object that is stitched together in the final binary, > that there's really no way around this, and I suppose it makes nice neat > little bite sized source files but for my case it was a surprise I hadn't > expected. > > After building a giant conglomeration I realised for some cases (namely, a > backend for a mobile app) that one has to design the folder tree to split > the parts. It's something to keep in mind for multi-function binaries if > you want to also offer single function binaries for specific parts that are > only needed alone. > > I am probably, as usual, doing something unconventional and running up > against things that nobody else ever thought of and discover something > about a system that isn't obvious until you think about it, when one > intends to do some particular thing. > > In terms of memory utilisation, there is really not a great deal of > difference in terms of performance, I presume, except providing the ability > to cut up the whole thing into small pieces, a tiny amount extra on disk > but I presume the final memory use, since all is a monolithic (more or > less) static binary, that once it unwraps all the entry points and relative > references that there isn't (much) extra in memory. I suppose also if one > is targeting a constrained environment, it would make sense to use -s -w to > strip out the debug symbols. > > -- > 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/36de6c0d-23fe-4dfa-ad9a-89d9734c9701%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/36de6c0d-23fe-4dfa-ad9a-89d9734c9701%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAA40n-XZ8Q6gQzMh9GtYHJOeUJve_m43eCBsr0KJJHaCJW9uaw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
