Quick update:
The issue was resolved after a `go clean`...
Now everything build just as if the directives are passed through the CLI.
I don't know what happened...
Thank all for your help!
On Tuesday, February 28, 2017 at 2:06:20 PM UTC-5, Chun Zhang wrote:
>
> Hi, All,
>
> I have googled
ah, sorry I didn't properly read the whole thread before posting
if it works for you when you set the flags through the CLI, but not when
you put them in a go file, then there is something wrong with how you
embedded the flags in you go file.
like Ian said, you need to define the flags in a
Thanks! I didn't write out libboost etc just to make sure that at least one
lib is correctly linked, if so, I should see other link errors and I can
just keep passing in required libs. This is exactly what happens when I
pass CGO_LDFLAGS= explicitly in the CLI.
However, when using the
ah okay, I had problems with the ".a" suffix myself, so I though it was
worth a shot.
I just know that this
>//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR
won't work, as the env variables won't be resolved by go afaik.
maybe test it with an absolute path instead
and/or use "go
Yes, I tried quite a few varieties, such as:
//#cgo LDFLAGS: $GOPATH/src/kflow/libcolor/lib/libCOLOR with/without .a
//#cgo LDFLAGS: ${SRCDIR}kflow/libcolor/lib/libCOLOR with/without .a
//#cgo LDFLAGS: -L${SRCDIR}kflow/libcolor/lib -l:libCOLOR with/without .a
//#cgo LDFLAGS:
did you try it without the ".a" suffix in the LDFLAGS?
Am Dienstag, 28. Februar 2017 20:06:20 UTC+1 schrieb Chun Zhang:
>
> Hi, All,
>
> I have googled quite a bit about this issue, there are some tutorials
> online. But most of them targeted either at older go releases or C instead
> of C++.
