I'm getting a similar error on Windows 10 with IntelliJ, even though it's
*not* cross-compiling...
Apparently IntelliJ needs "-N -l" for debugging (with delve...)
My installation was pretty standard (out of the box); but a simple:
package main
import "fmt"
func main() {
fmt.Print("hello")
}
fails with:
GOROOT=C:/Gosl/go
GOPATH=C:/MyGo
C:/Gosl/go\bin\go.exe build -o "C:\Users\pedro\AppData\Local\Temp\Build
hello.go and rungo" -gcflags "-N -l" C:/MyGo/src/tryagain/hello.go
# command-line-arguments
runtime.cgocall: nosplit stack overflow
584 assumed on entry to runtime.cgocall (nosplit)
528 after runtime.cgocall (nosplit) uses 56
...
Any ideas?
(thanks!)
On Monday, July 4, 2016 at 1:46:28 PM UTC+10, Ian Lance Taylor wrote:
>
> On Sun, Jul 3, 2016 at 8:07 PM, <velly...@gmail.com <javascript:>>
> wrote:
> > Build Env:
> >
> > Build tool: GoClipse
> > Windows(7):
> > Go Installation: go1.6.2 windows/amd64
> >
> > Under default build environment, every thing goes well. I could find
> the
> > .exe file in bin folder. But if I try to build target for linux with
> setting
> > environment:
> > GOOS=linux
> > GOARCH=amd64
> >
> > I will get the following error: (Copy from goclispe console)
> >
> > ************ Building Go project: personal.study ************
> > with GOPATH: E:\go_ws
> >>> Running: C:\Go\bin\go.exe install -v -gcflags "-N -l"
> personal.study/...
> > personal.study/go/main
> > # personal.study/go/main
> > runtime.typedslicecopy: nosplit stack overflow
> > 584 assumed on entry to runtime.typedslicecopy (nosplit)
> > 448 after runtime.typedslicecopy (nosplit) uses 136
> > 440 on entry to runtime.cgoCheckSliceCopy (nosplit)
> > 376 after runtime.cgoCheckSliceCopy (nosplit) uses 64
> > 368 on entry to runtime.cgoCheckTypedBlock (nosplit)
> > 168 after runtime.cgoCheckTypedBlock (nosplit) uses 200
> > 160 on entry to runtime.cgoCheckBits (nosplit)
> > 24 after runtime.cgoCheckBits (nosplit) uses 136
> > 16 on entry to runtime.cgoIsGoPointer (nosplit)
> > -32 after runtime.cgoIsGoPointer (nosplit) uses 48
> > runtime.sigtrampgo: nosplit stack overflow
> > 584 assumed on entry to runtime.sigtrampgo (nosplit)
> > 392 after runtime.sigtrampgo (nosplit) uses 192
> > 384 on entry to runtime.sigfwdgo (nosplit)
> > 288 after runtime.sigfwdgo (nosplit) uses 96
> > 280 on entry to runtime.dieFromSignal (nosplit)
> > 240 after runtime.dieFromSignal (nosplit) uses 40
> > 232 on entry to runtime.setsig (nosplit)
> > 40 after runtime.setsig (nosplit) uses 192
> > 32 on entry to runtime.funcPC (nosplit)
> > 0 after runtime.funcPC (nosplit) uses 32
> > -8 on entry to runtime.add (nosplit)
> > runtime.cgocallback_gofunc: nosplit stack overflow
> > 584 assumed on entry to runtime.cgocallback_gofunc (nosplit)
> > 576 after runtime.cgocallback_gofunc (nosplit) uses 8
> > 568 on entry to runtime.cgocallbackg (nosplit)
> > 480 after runtime.cgocallbackg (nosplit) uses 88
> > 472 on entry to runtime.exitsyscall (nosplit)
> > 352 after runtime.exitsyscall (nosplit) uses 120
> > 344 on entry to runtime.exitsyscallfast (nosplit)
> > 184 after runtime.exitsyscallfast (nosplit) uses 160
> > 176 on entry to runtime.writebarrierptr (nosplit)
> > 128 after runtime.writebarrierptr (nosplit) uses 48
> > 120 on entry to runtime.cgoCheckWriteBarrier (nosplit)
> > 56 after runtime.cgoCheckWriteBarrier (nosplit) uses 64
> > 48 on entry to runtime.cgoIsGoPointer (nosplit)
> > 0 after runtime.cgoIsGoPointer (nosplit) uses 48
> > -8 on entry to runtime.cgoInRange (nosplit)
> > ^^^ Terminated, exit code: 2 ^^^
> > ************ Build terminated. ************
> >
> > What's wrong with me? Any warier could help me ~ Thank you!
>
> It's arguably a bug, but not a very important one. The workaround is
> to not use "-N -l" for the runtime package.
>
> 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.
For more options, visit https://groups.google.com/d/optout.
