Strange error with GOOS=windows _OR_ GOARCH=386

[dmagyar]

I can not find any explanation to the error as Ctx is clearly defined in ctx.go. This only happens when GOOS=windows and or GOARCH=386. Trying with latest 1.10.2 golang:

dmagyar@dmtest:~/go/ossl$ GOOS=windows GOARCH=amd64 go get github.com/spacemonkeygo/openssl
# github.com/spacemonkeygo/openssl
../src/github.com/spacemonkeygo/openssl/net.go:24:7: undefined: Ctx
dmagyar@dmtest:~/go/ossl$ GOOS=linux GOARCH=amd64 go get github.com/spacemonkeygo/openssl
dmagyar@dmtest:~/go/ossl$ GOOS=linux GOARCH=386 go get github.com/spacemonkeygo/openssl
# github.com/spacemonkeygo/openssl
../src/github.com/spacemonkeygo/openssl/net.go:24:7: undefined: Ctx
dmagyar@dmtest:~/go/ossl$

Any ideas what this could be?

[rameshrv]

@dmagyar , I think this code (net.go:24) needs cgo. So, we need to set atleast 2 environment variables:

- CGO_ENABLED (set to 1)
- CC (path to the c compiler)

I had the same issue, and got this resolved by adding these 2 environment variables along with GOOS and GOARCH

Hope it helps.

[dmagyar]

@rameshrv thanks for the response. I tried again with these set and still no luck:

$ GOOS=windows GOARCH=386 CGO=1 CC=/mingw32/bin/i686-w64-mingw32-gcc.exe go get github.com/spacemonkeygo/openssl
# github.com/spacemonkeygo/openssl
..\..\go\src\github.com\spacemonkeygo\openssl\net.go:24:7: undefined: Ctx

Of course my C compiler is fully functional and can produce windows/386 executables.

$ /mingw32/bin/i686-w64-mingw32-gcc.exe test.c -o t.exe && ./t.exe
Hello World!

[rameshrv]

@dmagyar , interesting. It is definitely unable to link to the c libraries. I was actually referring to a GitHub issue/thread which gives the correct command line to resolve such cross compile errors for windows binaries. Here you go:

https://github.com/mattn/go-sqlite3/issues/303

Can you please check if that helps ?

[dmagyar]

Thanks for the article it works now! This was the final cmdline that got it to work. It seems pkg-config also failed me, which is strange as if I run it manually it returns the right CFLAGS/LDFLAGS...

$ GOOS=windows GOARCH=386 CGO_ENABLED=1 CGO_LDFLAGS="-L/usr/local/ssl/lib -lcrypto -lws2_32 -lgdi32 -lcrypt32" CGO_CFLAGS=-I/usr/local/ssl/include go get github.com/spacemonkeygo/openssl
$

[rameshrv]

@dmagyar great to know that your issue is fixed !

[jdgiotta]

I get this error when compiling for linux. Anyone else experience this?

[zeebo]

Do you have more details about your environment? For example, can you paste the output of go env?

[jdgiotta]

$ go env GOARCH="amd64" GOBIN="" GOCACHE="/Users/jdgiotta/Library/Caches/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/jdgiotta/go" GORACE="" GOROOT="/usr/local/Cellar/go/1.10.3/libexec" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.10.3/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/00/qt6j_f293lbg2zb6wtllshbw02z8t5/T/go-build509374766=/tmp/go-build -gno-record-gcc-switches -fno-common"

[zeebo]

Interesting. Can you show me the output of go build -x github.com/spacemonkeygo.openssl?

[jdgiotta]

Building for Mac works fine:

$ go build -x github.com/spacemonkeygo/openssl WORK=/var/folders/00/qt6j_f293lbg2zb6wtllshbw02z8t5/T/go-build220919097

Building for linux fails:

$ GOOS=linux GOARCH=amd64 go build -x github.com/spacemonkeygo/openssl WORK=/var/folders/00/qt6j_f293lbg2zb6wtllshbw02z8t5/T/go-build101968133 mkdir -p $WORK/b001/ cat >$WORK/b001/importcfg << 'EOF' # internal

import config

packagefile errors=/Users/jdgiotta/Library/Caches/go-build/72/72d97596222242b663ea40064ae019a6ca6d35e76a898353f345bab06003d890-d packagefile fmt=/Users/jdgiotta/Library/Caches/go-build/a7/a7e7e8488616e1f1ffe98b76cd3ee5806962282fb55871b445eb68c6e59e0b6f-d packagefile github.com/spacemonkeygo/openssl/utils=/Users/jdgiotta/Library/Caches/go-build/f5/f5b48ca219dac6687197a06fe3c303af0f2691d2c104bb10b1d9a7085ab3374a-d packagefile github.com/spacemonkeygo/spacelog=/Users/jdgiotta/Library/Caches/go-build/d9/d9aec4cd43aceef772ed3036b215b6d04523c239a351bfdafe20517d8822904e-d packagefile io=/Users/jdgiotta/Library/Caches/go-build/37/371c0be6bbb8dfec07a683abe92fd22c15c29bafdff53175d67831615fa0ca4a-d packagefile io/ioutil=/Users/jdgiotta/Library/Caches/go-build/d0/d09e2e17bd9efe5bdef8b5d1100fc0b3ef82690f7f3e957d81e5ec4d9a4fb172-d packagefile math/big=/Users/jdgiotta/Library/Caches/go-build/09/09ef3d7e1685c60c4663216c03b508aad428469b2587ff2461f67a86a6a0dcee-d packagefile net=/Users/jdgiotta/Library/Caches/go-build/76/76e3b20da42f98465f0b23649b382ffd37b5cf4c0d1b1ab2b6a6b3036fbd3adf-d packagefile net/http=/Users/jdgiotta/Library/Caches/go-build/62/629ba01624d3a6d2913589b71e9f2c65dc18d971f0d13d69eedadf07eb7971e7-d packagefile os=/Users/jdgiotta/Library/Caches/go-build/1a/1affbd65da62f47de5e46ebe5772d042d8e810d7a3bc011b1a3f941c84366476-d packagefile reflect=/Users/jdgiotta/Library/Caches/go-build/bb/bb76a8bb647a92893d4b9ac3c0b1afd953ceb8382448b474865fbf68f3f1e9b5-d packagefile regexp=/Users/jdgiotta/Library/Caches/go-build/1b/1bec9fae50e803202ddfb838db5f10f418bd27f7206cfb6ae18bf852627c6c03-d packagefile runtime=/Users/jdgiotta/Library/Caches/go-build/52/52f9e2efc1dc696961ede048318b8745a0ca1f7eb9d8dd4838694988ace14bad-d packagefile strings=/Users/jdgiotta/Library/Caches/go-build/b4/b4cce2eabf0872848904909410f3cd461ea3781773bf3be2a9449a57ed1ed54b-d packagefile sync=/Users/jdgiotta/Library/Caches/go-build/f7/f72513e3cdd027f4b76730dc8aad655d148a9212a56651ebd2239f07dfeb4209-d packagefile time=/Users/jdgiotta/Library/Caches/go-build/81/8121f8c0b6cd58c05fc0a47e53b2aa4f052cc02775a2d35fa3a00bfe166e60aa-d EOF cd /Users/jdgiotta/go/src/github.com/spacemonkeygo/openssl /usr/local/Cellar/go/1.10.3/libexec/pkg/tool/darwin_amd64/compile -o $WORK/b001/pkg.a -trimpath $WORK/b001 -p github.com/spacemonkeygo/openssl -complete -buildid 4a0FWLQrPexTStswtm1D/4a0FWLQrPexTStswtm1D -goversion go1.10.3 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./http.go ./net.go ./nid.go ./pem.go

github.com/spacemonkeygo/openssl

go/src/github.com/spacemonkeygo/openssl/net.go:24:7: undefined: Ctx

[zeebo]

You need to have a C cross compiler installed, and configure the Go toolchain to use it in order to compile for a different operating system.

I now realize that this also is the problem the original person had. Getting cross compilation set up is outside of the scope of this project, and OpenSSL is quite "fun" to attempt to cross compile in my experience. I would suggest trying to do the build natively.

[jdgiotta]

That is too bad this isn't in scope. This is one of the best solutions I've come across for openssl compliancy with Go. Really not being able to compile your module into a project just kills it's value.

[azdagron]

The reason it is out of scope is because it really has nothing to do with Go, and much more to do with cross-compiling openssl. Once you have successfully cross-compiled openssl, configuring Go to use your cross compilation toolchain is pretty straightforward. There are a good number of resources out there that can help.

Cross-compilation using a macOS host can be a colossal pain. Getting a macOS toolchain targeting linux can be very easy or very hard depending on your requirements. If you are targeting linux/amd64 then you can probably download a prebuilt one (brew even has some available if you are ok using musl). If you have requirements around architecture (e.g. ARM) and C library (e.g. gcc, musl, uclibc) then things get a little trickier. You can use something like crosstool-ng to build a toolchain, but not without pain (mostly due to gnu tool behavior and file system case sensitivity).

Other platforms aren't as difficult. I've successfully cross-compiled openssl (and this wrapper) for windows from linux, but that was considerably easier because mingw-w64 toolchains are readily available on linux.

[jdgiotta]

I was aiming to build against a docker image. That way it is native, but I'll continue at some later time with getting openssl compiling. Unfortunately at the moment no time.

[dmagyar]

As I pasted in my response above my cross compiler toolchain was there and was fully functional. I have succesfully compuled OpenSSL right before trying your package. I can try again, it's been some time.

Qq: are openssl engines supported? I badly need the CAPI engine to interface with windows keystores.