Potentially dumb question on compiling under Windows

[an0nym05]

I'm trying to build a project using go-duckdb under Win11 with Mingw64 (myself rather an OSX user) and experiencing the following:

$ go version
go version go1.19.7 windows/386

$ CGO_ENABLED=1 CGO_LDFLAGS="-L/d/Projects/duckdb/build/release/src" go build -v -tags=duckdb_use_lib -o bin/sample.exe main.go
github.com/marcboeker/go-duckdb
# github.com/marcboeker/go-duckdb
vendor\github.com\marcboeker\go-duckdb\rows.go:275:11: array length 1 << 31 (untyped int constant 2147483648) must be integer
vendor\github.com\marcboeker\go-duckdb\rows.go:381:44: cannot use value (variable of type _Ctype_struct___7) as type [4]byte in struct literal
vendor\github.com\marcboeker\go-duckdb\rows.go:381:49: too few values in _Ctype_struct___6{…}

Same issue when trying to build in PS1 shell:

PS D:\Projects\app> $env:CGO_ENABLED=1
PS D:\Projects\app> $env:CGO_LDFLAGS="-LD:\Projects\app\lib\libduckdb-windows-amd64"
PS D:\Projects\app> go build -v -tags=duckdb_use_lib -o bin\app.exe .\main.go
github.com/marcboeker/go-duckdb
# github.com/marcboeker/go-duckdb
vendor\github.com\marcboeker\go-duckdb\rows.go:275:11: array length 1 << 31 (untyped int constant 2147483648) must be integer
vendor\github.com\marcboeker\go-duckdb\rows.go:381:44: cannot use value (variable of type _Ctype_struct___7) as type [4]byte in struct literal
vendor\github.com\marcboeker\go-duckdb\rows.go:381:49: too few values in _Ctype_struct___6{…}

Any guidelines/help welcome!

[marcboeker]

Hi,

is there a reason, why you are compiling for a 32 bit architecture (windows/386)? Maybe this could be the reason, why errors like array length 1 << 31 (untyped int constant 2147483648) must be integer happen.

Could you please try it again for a 64 bit architecture?

[an0nym05]

Hi @marcboeker
Thank you for the hint. Indeed, re-installed Go (didn't pay enough attention to windows/386 part of the version output) and that helped to move forward with compilation. But I ended up with issues that have been reported earlier (e.g. #22)

I think we could close this one and now it's resolved to an already reported problem...

Thank you!