Static linking in 0.1.0

[metral]

Is this command:

GOPATH=/path/to/gb/project/vendor:/path/to/gb/project CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags '-w -extld ld -extldflags -static' -a -x .

listed in #81 (comment) still the recommended way of building static bins as far as gb is concerned?

I primarily ask because i see that with the cross-compilation support in 0.1.0, builds for other architectures are statically linked, so I can only assume gb is handling static linking to some extent and was wondering if that functionality is going to be added to the native host gb builds (i.e. my host is GOOS=linux GOARCH=amd64 but gb build only allows me to create dynamically linked bins)

[pierrebeaucamp]

+1

[metral]

@davecheney bump

[davecheney]

Thank you. I have not forgotten about this issue, but it is not on my current shortlist (you can see the roadmap in the README).

I've added the help wanted tag to this issue, but please discuss your design before you start coding should you decide to work on this.

[doherty]

That command is pretty horrid. It'd be nice to have a simple --make-it-static flag that figures out and uses the right incantation for you.

[profer]

I've submitted a pull request which works around this issue by considering all packages, including the standard library, as stale when building with gb build -a -f.
To build static binaries for ones host platform the command is then just CGO_ENABLED=0 gb build -a -f

@davecheney: Sorry for submitting this before discussing my design – I saw your comment above just now.

[davecheney]

👎 to #649.

I think a better solution would be to make the CGO enabled state of a package part of the isStale computation. This will also probably need a build tag, cgo or something so the state can be recorded correctly.

This is probably going to mess up recompiling the stdlib as gb does not expect it to be in the PROJECT/pkg directory, but there is no reason it cannot be, it'll just take some refactoring.