windows build exit status 0xc0000135

[marcboeker]

windows build exit status 0xc0000135

[marcboeker]

Could you please post the complete command, you are using to compile your Go program and the output? As I don't have access to a Windows VM with an amd64 architecture to run goduckdb, I can only guess what is wrong.

[sdmcallister]

Thanks for responding. I am building using go run .. what I posted above is the only output. If I run go build . then run the binary there is no output.

[marcboeker]

Have you tried setting the CGO_LDFLAGS and CGO_CFLAGS env flags to point to your DuckDB DLL and the header file like it is mentioned in the README?

(Please adjust the path. I have no idea how a correct path under Windows should look like. Sth. like C:/path/to/libduckdb.dll or so?)

CGO_LDFLAGS="-L/path/to/libduckdb.dll" CGO_CFLAGS="-I/path/to/duckdb.h" go run examples/simple.go

[sdmcallister]

Yes, I've used the following commands which I believe are the equivalent in powershell:

$env:DYLD_LIBRARY_PATH = 'C:\duckdb\libduckdb-windows-amd64\duckdb.dll'
$env:CGO_LDFLAGS = '-LC:\duckdb\libduckdb-windows-amd64\duckdb.dll'
$env:CGO_CFLAGS = '-IC:\duckdb\libduckdb-windows-amd64'

If I build then the program fails silently. Same thing with Git Bash terminal. Will try with WSL. I had it working at one point (#4) but same steps don't seem to work now.

[marcboeker]

Have you had a chance to get it working on WSL?

The DYLD_LIBRARY_PATH is only for macOS. Does the CGO_CFLAGS env var point to the directory with the duckdb.h file? What happens if you specify a wrong path to either the duckdb.dll or duckdb.h? Does Go complain about this or do you receive the same exit status?

[sdmcallister]

Go complains more when it can't find the header file or dll. I've tried a variety of different path combinations / compiler flags. Right now it should be finding duckdb.h and duckdb.dll given the location of these files. I've used the library in the past on linux and windows.

[marcboeker]

Ah okay. Have you downloaded the most recent version of DuckDB? Thera have been significant changes compared to the version some months ago. Maybe this could be the problem.

[sdmcallister]

For duckdb I'm using 0.3.4 precompiled, which I believe is the latest. My Go version is 1.18.2.

[sdmcallister]

@marcboeker

Also running into issues on WSL2 Ubuntu:

I've installed Go 1.18.2 and successfully compiled a couple Go programs. I installed gcc. I downloaded the latest compiled duckdb linux binaries (duckdb.h and libduckdb.so) 0.3.4.

I copied the script from example.go file into my own file main.go for testing

Directory:

~/test$ ls
duckdb.h  duckdb.hpp  go.mod  go.sum  libduckdb.so  main.go

I then run:

~/test$ CGO_LDFLAGS="-L/home/me/test/libduckdb.so" CGO_CFLAGS="-I/home/me/test" go run .
# github.com/marcboeker/go-duckdb
/usr/bin/ld: cannot find -lduckdb
collect2: error: ld returned 1 exit status

I also tried:

CGO_LDFLAGS="-L/home/me/test" CGO_CFLAGS="-I/home/me/test" go run .
/tmp/go-build3660599155/b001/exe/testduckdb: error while loading shared libraries: libduckdb.so: cannot open shared object file: No such file or directory
exit status 127

[marcboeker]

Does running make examples or make test work on WSL2? If so, please have a look at the Makefile to see, what the required env variables are.

[sdmcallister]

Thanks, this works (WSL)!
LIB=libduckdb.so CGO_LDFLAGS="-L/home/me/test" CGO_CFLAGS="-I/home/me/test" go run -ldflags="-r /home/me/test" main.go

[an0nym05]

Compiling under WSL produces linux binary. What if a windows binary is required?

[marcboeker]

I was never able to successfully cross-compile go-duckdb for Windows. Either the compilation took hours and never finished or the resulting binary was crashing. But I also had no access to a native Windows host. It was either emulated or cross compiling.

Have you tried running your Go code with linking to the precompiled DockDB Windows libs instead of compiling DuckDB from the sources?

[sdmcallister]

As an alternative, you could checkout the odbc driver? But I do appreciate the work here and challenges faced with Windows.

[an0nym05]

Have you tried running your Go code with linking to the precompiled DockDB Windows libs instead of compiling DuckDB from the sources?

I tried your windows-builds branch, took some time to create precompiled win lib file. I tried to run then sample specifing it

alexa@gamebox MINGW64 /d/Projects/go-duckdb (windows-builds)
$ CGO_ENABLE=1 GOOS=windows GOARCH=amd64 CGO_LDFLAGS="-L$(PWD)/deps/windows_amd64"  CGO_CFLAGS="-I$(PWD)" go run -v -x -p 8 examples/simple.go

it took again around forever on my windows box and ended up with:

...
packagefile internal/intern=C:\Users\alexa\AppData\Local\go-build\51\51df8b5beba6d664ef42613fb621d6b20366e61e044eca9b03c6b081ae52f5dd-d
modinfo "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tcommand-line-arguments\ndep\tgithub.com/marcboeker/go-duckdb\t(devel)\t\ndep\tgithub.com/mitchellh/mapstructure\tv1.5.0\th1:jeMsZIYE/09sWLaz43PL7Gy6RuMjD2eJVyuac5Z2hdY=\nbuild\t-buildmode=exe\nbuild\t-compiler=gc\nbuild\tCGO_ENABLED=1\nbuild\tCGO_CFLAGS=-ID:/Projects/go-duckdb\nbuild\tCGO_CPPFLAGS=\nbuild\tCGO_CXXFLAGS=\nbuild\tCGO_LDFLAGS=-LD:/Projects/go-duckdb/deps/windows_amd64\nbuild\tGOARCH=amd64\nbuild\tGOOS=windows\nbuild\tGOAMD64=v1\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
EOF
mkdir -p $WORK\b001\exe\
cd .
"C:\\Program Files\\Go\\pkg\\tool\\windows_amd64\\link.exe" -o "$WORK\\b001\\exe\\simple.exe" -importcfg "$WORK\\b001\\importcfg.link" -s -w -buildmode=pie -buildid=VzwRJo0OF2XxIb69JnCJ/NQsc7hGM47_cU0ATWxXa/mLFgwvTCSD_2sOanif-B/VzwRJo0OF2XxIb69JnCJ -extld=g++ "$WORK\\b001\\_pkg_.a"
# command-line-arguments
C:\Program Files\Go\pkg\tool\windows_amd64\link.exe: running g++ failed: exit status 1
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ldl: No such file or directory
collect2.exe: error: ld returned 1 exit status

The content of the deps folder:

PS D:\Projects\go-duckdb> dir .\deps\darwin_arm64\


    Directory: D:\Projects\go-duckdb\deps\darwin_arm64


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         3/29/2023   5:40 PM       45269944 libduckdb.a
-a----         3/22/2023   2:09 PM            118 vendor.go

I'm fine running more tests, though I miss some knowledge of C/C++ buildchain and thus would require some guidance here...

[an0nym05]

As an alternative, you could checkout the odbc driver? But I do appreciate the work here and challenges faced with Windows.

this is one of my last resorts... before i fallback to calling duckdb executable as separate process and communicate with it via stdin/out :) but Go's support of ODBC is also... shady so to say.

[an0nym05]

As an alternative, you could checkout the odbc driver? But I do appreciate the work here and challenges faced with Windows.

@sdmcallister Just checked ODBC driver. Looks like Go's support for ODBC was... as expected: alexbrainman/odbc#186