To answer this question (after talking on Gopher Slack about this one)… As the 
target is a 32bit architecture, that max size is max_uint32/4

Sander



On 21/08/2017, at 11:32 , Sander van Harmelen <san...@xanzy.io> wrote:

I’ve made some nice progression and am able to generate all kinds of binaries 
for my mips system now. But I just got a new challenge… When trying to cross 
compile something that uses pocketsphinx I get this output:

GOOS=linux GOARCH=mipsle CGO_ENABLED=1 
CC=OpenWrt-Toolchain-ramips-mt7688_gcc-4.8-linaro_uClibc-0.9.33.2.Darwin-x86_64/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-uclibc-gcc-4.8.3
 
PKG_CONFIG_LIBDIR=portaudio-mips/lib/pkgconfig:sphinxbase-mips/lib/pkgconfig:/pocketsphinx-mips/lib/pkgconfig
 go build

# github.com/xlab/pocketsphinx-go/pocketsphinx 
<http://github.com/xlab/pocketsphinx-go/pocketsphinx>
../../../xlab/pocketsphinx-go/pocketsphinx/pocketsphinx.go:142: type 
[2147483647]byte larger than address space
../../../xlab/pocketsphinx-go/pocketsphinx/pocketsphinx.go:1248: type 
[2147483647]uint32 larger than address space
../../../xlab/pocketsphinx-go/pocketsphinx/pocketsphinx.go:1248: type 
[2147483647]uint32 too large

Is there a compile option I need to use to fix this? Or is the problem in the 
types used by pocketsphinx.go in conjunction with my target architecture?

Sander



On 26/07/2017, at 07:23 , Sander van Harmelen <san...@xanzy.io 
<mailto:san...@xanzy.io>> wrote:

Thanks for all your help!! Will have a look and play with some options...

Sander

On 26 Jul 2017, at 03:05, Ian Lance Taylor <i...@golang.org 
<mailto:i...@golang.org>> wrote:

> On Sat, Jul 22, 2017 at 12:57 PM, Sander van Harmelen <san...@xanzy.io 
> <mailto:san...@xanzy.io>> wrote:
> 
> Ok, I managed to get it compiled by first cross compiling libusb and then 
> pointing to it using the linker flags you suggested. So thank you very much, 
> I can now compile a binary that works on the target device :)
> 
> I do have one additional question… Is it possible to make the resulting 
> binary statically linked, just as standard Go binaries are? Is isn’t that 
> possible?

It should be possible, but it kind of depends on your C toolchain.
The basic idea is
  go install -ldflags=-extldflags=-static

Ian


-- 
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 
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout 
<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