cmd/link: package versioning for shared libraries is incompatible with linkobj builds #24512
During linkobj builds, __.PKGDEF files are still included in the linker object files, but they're empty stub files that only contain information already present in the .o file, so I'm looking at getting rid of them in that case.
Working on cmd/link, I notice that genhash (used for generating package versions from the __.PKGDEF files for shared library builds) makes two assumptions that are incompatible with this:
My plan here is:
The text was updated successfully, but these errors were encountered:
This is currently always the case because loadobjfile complains if it's not, but that will be changed soon. Updates #24512. Change-Id: I262daca765932a0f4cea3fcc1cc80ca90de07a59 Reviewed-on: https://go-review.googlesource.com/102280 Run-TryBot: Matthew Dempsky <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Ian Lance Taylor <firstname.lastname@example.org>
The __.PKGDEF file is a compiler object file only intended for other compilers. Also, for build systems that use -linkobj, all of the information it contains is present within the linker object files already, so look for it there instead. This requires a little bit of code reorganization. Significantly, previously when loading an archive file, the __.PKGDEF file was authoritative on whether the package was "main" and/or "safe". Now that we're using the Go object files instead, there's the issue that there can be multiple Go object files in an archive (because when using assembly, each assembly file becomes its own additional object file). The solution taken here is to check if any object file within the package declares itself as "main" and/or "safe". Updates #24512. Change-Id: I70243a293bdf34b8555c0bf1833f8933b2809449 Reviewed-on: https://go-review.googlesource.com/102281 Run-TryBot: Matthew Dempsky <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Ian Lance Taylor <email@example.com>
By always writing out pack files, the object file format can be simplified somewhat. In particular, the export data format will no longer require escaping, because the pack file provides appropriate framing. This CL does not affect build systems that use -pack, which includes all major Go build systems (cmd/go, gb, bazel). Also, existing package import logic already distinguishes pack/object files based on file contents rather than file extension. The only exception is cmd/pack, which specially handled object files created by cmd/compile when used with the 'c' mode. This mode is extended to now recognize the pack files produced by cmd/compile and handle them as before. Passes toolstash-check. Updates #21705. Updates #24512. Change-Id: Idf131013bfebd73a5cde7e087eb19964503a9422 Reviewed-on: https://go-review.googlesource.com/102236 Run-TryBot: Matthew Dempsky <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Ian Lance Taylor <firstname.lastname@example.org>