cmd/link: shared object constructor functions are not invoked with internal linker and musl libc #28909
What version of Go are you using (
The text was updated successfully, but these errors were encountered:
It looks to me that the internal linker does not link against
Preamble - I am no expert in ELF or Linux ABI. I will try to digest the information and draw (hopefully) correct conclusions:
For me, a core statement in Rich Felkers reply to my inquiry was
It seems, that neither with glibc nor with musl libc
Using the external (system) linker or linking crt code with internal linker, solves the
Thus, my first take away would be to either promote using the external linker or make internal linker linking crt code. At least users should be made aware about potential consequences using the internal linker.
@Hollerberg From a glibc perspective, this is mainly a forward compatibility problem. There is a lot of code in
Anyway, the current internal linker behavior breaks these things for glibc, as far as I can tell:
I have not checked whether the Go linker uses
On the glibc side, we need to take the existing Go binaries into account going forward. It would have been nice if we could have switched to the simpler musl approach (I have a patch that changes
For what it's worth, the internal linker is only used for pure Go programs that are not linked against any C code. Such programs have no constructors. I suppose it's true that
The point of internal linking mode is to permit building Go programs without having a C development environment installed. Admittedly this case is uninteresting on GNU/Linux; it is more useful on Darwin and Windows.
I see your point - definitely, requiring external linker would reduce Go quality of service for developers.
I see three issues for (more or less) pure Go programs:
Could Go startup code call
I'm perfectly comfortable in saying that anybody who wants to use
Static vs dynamic linking is not a matter of preference. With glibc and static linking, many things simply do not work, and you do a disservice to your users by pretending otherwise (particularly when they hard-code static linking because it happens to work on amd64 at present, but breaks horribly on other architectures).
The purpose of internal linking is to avoid requiring C development tools. It wouldn't make sense to start linking against crt1.o, etc., even if we were able to keep up with the many variations. If internal linking can't work, then it can't work; we shouldn't try to make it more like external linking. When using external linking, then of course the external linker is responsible for choosing the startup object files.
Regarding static linking, we aren't pretending anything one way or another. Our users want static linking, and they do so by passing