Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Given a file lib.go:
The following command sequence prints 42 as expected:
If one now changes 42 to 43 in lib.go, the following command sequence still prints 42:
rather than 43. The issue is (presumably) that lib.F() got inlined and there's (apparently) no check in the linker that lib.go changed.
While not surprising to an initiated user, this is surprising to an unsuspecting user. Ideally the linker, or then the initialization code should check that a compiler package we link again (or that we initialize) is the same that we compiled against. This could be done with some fingerprint of sorts, perhaps computed on the export data only.
I suspect scenarios can be created where the linker succeeds and the program crashes (because a data type changed in lib.go and main.go wasn't recompiled).
This behavior is no different from C/C++ where we have "independent" compilation: as long as the linker finds the matching symbols, it doesn't care whether they are referring to the same entities that were implied in the source code - hence the independence.
Go should properly implement "separate" compilation: packages can be compiled separately, but correspondence to source code should be enforced.