Ah, I should update that I don't really maintain this any longer since there are better tools these days. The best of which I've found is xgo (which supports cgo): https://github.com/karalabe/xgo
On Mon, Jan 9, 2017 at 1:16 PM, Dave Mazzoni <dav...@gmail.com> wrote: > This looked really nice, but I'm having problems with it: > go get github.com/mitchellh/gox > (no problem) > go get github.com/inconshreveable/gonative > # github.com/inconshreveable/gonative > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:67: > cannot use "" (type string) as type bool in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:67: > cannot use nil as type string in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:67: > too few values in struct initializer > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:68: > cannot use "" (type string) as type bool in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:68: > cannot use nil as type string in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:68: > too few values in struct initializer > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:69: > cannot use "" (type string) as type bool in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:69: > cannot use nil as type string in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:69: > too few values in struct initializer > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:70: > cannot use "" (type string) as type bool in field value > Projects/Golang/src/github.com/inconshreveable/gonative/gonative.go:70: > too many errors > > Any idea what's wrong? > > On Monday, May 5, 2014 at 3:06:49 PM UTC-4, Alan Shreve wrote: >> >> Kinda - >> >> You don’t really want gox to rebuild the toolchain, it’s already built >> for you. Although it technically shouldn’t break anything if it doesn’t >> force a rebuild of the libraries. You also don’t need to set any env >> variables in your gonative call. Something like this should do the trick: >> >> $ go get github.com/mitchellh/gox >> $ go get github.com/inconshreveable/gonative >> $ cd /your/project >> $ gonative >> $ PATH=$PWD/go/bin/:$PATH gox >> >> You’ll get errors for platforms that gonative doesn’t support >> (openbsd/freebsd/plan9), but the rest should work just fine. >> >> - alan >> >> On May 4, 2014, at 3:54 PM, Robert <robert...@gmail.com> wrote: >> >> After some playing around, I'm pretty sure this does the business: >> >> $ GOROOT=$PWD/go PATH=$PWD/go/bin:$PATH gonative >> $ GOROOT=$PWD/go PATH=$PWD/go/bin:$PATH gox -build-toolchain >> $ GOROOT=$PWD/go PATH=$PWD/go/bin:$PATH gox >> >> On Sunday, May 4, 2014 2:32:42 PM UTC-7, Robert wrote: >>> >>> Can you post an example of how to use gonative with gox to do an actual >>> cross-compilation? >>> >>> gonative builds the toolchain, but does not actually cross-compile... >>> >>> On Wednesday, April 30, 2014 7:02:48 PM UTC-7, Alan Shreve wrote: >>>> >>>> I’ve automated this approach for anyone to use: >>>> >>>> https://github.com/inconshreveable/gonative >>>> >>>> And it works! Almost! >>>> >>>> I’ve tested linux/darwin/windows on 386/amd64 (not freebsd or linux/arm >>>> yet) and everything seems to work great except . . . >>>> >>>> When I try to run linux_386 binaries on linux_amd64 machines. A simple >>>> hello world works, but if I try to use something that requires a native >>>> library like this: >>>> >>>> // test.go >>>> package main >>>> >>>> import ( >>>> "fmt" >>>> "os/user" >>>> ) >>>> func main() { >>>> u, err := user.Current() >>>> fmt.Printf("%v %v\n", u, err) >>>> } >>>> >>>> I get a really weird error: >>>> >>>> alan@inconshreveable:~$ ./test >>>> -bash: ./test: No such file or directory >>>> >>>> Any ideas on what could possibly be going on? >>>> >>>> - alan >>>> >>>> On Apr 27, 2014, at 12:42 PM, minux <minu...@gmail.com> wrote: >>>> >>>> >>>> On Sun, Apr 27, 2014 at 2:05 PM, Rob Napier <robn...@gmail.com> wrote: >>>> >>>>> I work on an appliance that includes a cross-platform Go client >>>>> distributed by the appliance. I'd like to embed appliance-specific >>>>> configuration into the client executable. It occurred to me that I could >>>>> just ship the client source code and cross-compile it on the appliance >>>>> passing -X linker flags to set various defaults. While that has worked >>>>> well >>>>> in basic experiments (and is insanely fast and simple to implement), the >>>>> problem is that it interferes with cgo. While my app doesn't have any cgo >>>>> of its own, it relies on the native network resolver and http certificate >>>>> verifiers (Darwin) that require cgo. Even if I could work around those >>>>> specifics, I don't want to box myself into a situation where I can never >>>>> ship cgo. >>>>> >>>>> (I've looked at https://code.google.com/p/g >>>>> o/source/detail?r=6d3bdbd27761, but I assume this would require a >>>>> full C cross-compilation setup? This seems a lot of complexity, but >>>>> perhaps >>>>> I'm overestimating? My appliance is unix, and I need to build Mac and >>>>> Windows.) >>>>> >>>>> Is there an effective way to relink an already-built executable with >>>>> new -X flags in a cross-compiling way? I assume that I can ship a pkg >>>>> directory of all the compiled packages and 6l/8l it on demand, but is that >>>>> going to work with cross-linking cgo that requires dynamic libraries that >>>>> won't be on the linking system? I assume I would also need to include pkg >>>>> objects for all the stdlib things I use. Is there a good way to work >>>>> everything that is required? Or is there a simpler way to just change the >>>>> -X values without relinking the object files? >>>>> >>>>> I'm open to other approaches (like attaching configuration data to the >>>>> end of the executable), but -X settings seemed such a clean solution until >>>>> I ran into the cgo issues... :) >>>>> >>>> If the only cgo-dependent packages are in the standard library, then >>>> you do have workaround >>>> without setting up a full cross compilation environment. >>>> >>>> Download the binary distribution for the target platform, extract the >>>> pkg/$GOOS_$GOARCH directory >>>> into your $GOROOT/pkg (your go installation must have the same version >>>> as the binary distribution, >>>> and your go installation must support the architecture you're >>>> building), then do this to build your application: >>>> >>>> GOOS=target_OS GOARCH=target_ARCH go build -ldflags '-X main.something >>>> "value" -linkmode internal' importpath >>>> >>>> NOTE: >>>> 1. make sure the timestamp of all the source files in your $GOROOT is >>>> older than any of the >>>> *.a file in $GOROOT/pkg/$GOOS_$GOARCH that you extracted from the >>>> binary distribution, >>>> otherwise the above command will try to rebuild the foreign packages. >>>> 2. you probably also need to copy a few generate source file from the >>>> binary distribution. all >>>> of them are in the runtime package, and with the prefix "z". >>>> cp -p /path/to/extracted/go/src/pkg/runtime/z*_$GOOS_$GOARCH.* >>>> $GOROOT/src/pkg/runtime >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
