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.

Reply via email to