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.

Reply via email to