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 <javascript:>> > 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/go/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 <javascript:>. > 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.
