On 16 July 2016 at 15:40, Peter Colberg <pe...@colberg.org> wrote: > On Fri, Jul 15, 2016 at 04:04:26PM -0700, Tianon Gravi wrote: >> - the "Build-Profiles" bits -- I know we should be using >> build-profiles more intelligently throughout src:golang-X.Y, but is >> there something specific to PIE itself that makes it more >> necessary/appropriate than in the normal case? > > It is not specific to PIE. When cross-compiling golang, the generated > compiler cannot be executed on the host, so the stdlib with PIE mode > cannot be built using that compiler.
Can we leave fixing the package to be cross-compilable to a separate effort? It ought to be possible but seems indepedent. > I have to admit that I did not look at the golang build process in > detail yet. When finished, does it leave a stage1 compiler for the > host that could be reused to cross-compile PIE stdlib? I'm not entirely sure what the question means, but I think the answer is "yes". The Go story for cross compilation is quite good, although cgo makes things a bit awkward. We'll need some kind of GOARCH -> triplet mapping somewhere I guess. >> - "golang-X.Y-go.install" currently has "pkg/*_* >> /usr/lib/go-X.Y/pkg/", which will still match >> "pkg/linux_amd64_shared", and thus include these files _both_ in >> "golang-1.6-std-pie" and "golang-1.6-go" -- I guess we need to fix >> that by using "dh_exec" and passing through our GOOS and GOARCH values >> instead of using globs? > > That was my first and preferred solution, but I could not make dh_exec > pass GOARCH to the .install scripts, while DEB_HOST_MULTIARCH is passed > just fine. So now override_dh_install-arch moves the PIE stdlib to the > correct package after dh_install. Yeah, we don't define GOARCH in rules directly any more. I guess you could do something override_dh_install:\n\t$(CURDIR)/debian/helpers/goenv.sh dh_install but that seems a bit nutty. Cheers, mwh