Open metral opened 9 years ago
+1
@davecheney bump
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.
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.
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.
👎 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.
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 https://github.com/constabulary/gb/issues/81#issuecomment-111466307 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
butgb build
only allows me to create dynamically linked bins)