Static linking on Windows broken

[marcboeker]

Static linking on Windows broken

[ZenLiuCN]

Hi, I just try to using static link under windows.

1. compile a static lib from duckdb source (mingw)
2. link it with go-duckdb
3. run into the same trouble
4. found inside duckdb.h

//
// duckdb.h
//
//
//===----------------------------------------------------------------------===//

#pragma once

// duplicate of duckdb/main/winapi.hpp
#ifndef DUCKDB_API
#ifdef _WIN32
#if defined(DUCKDB_BUILD_LIBRARY) && !defined(DUCKDB_BUILD_LOADABLE_EXTENSION)
#define DUCKDB_API __declspec(dllexport)
#else
#define DUCKDB_API //__declspec(dllimport) // !! here 
#endif

5. comment out that part makes no link error when compile.

[candiduslynx]

Hi @marcboeker!
Can I suggest trying with https://github.com/ebitengine/purego instead of cgo?

[candiduslynx]

I also found the following issue that might be of use: golang/go#51007 (comment)

Could you try reproducing with Go 1.20+?

[marcboeker]

I'm sorry, I only had access to a amd64 Windows VM for a short period of time to test this. ATM I'm not able to setup a amd64 based Windows VM on my M1 Mac, so I can't reproduce this. Do you have access to a Windows machine to test this with 1.20+?

[candiduslynx]

No, unfortunately. I was looking into the issue for cloudquery/cloudquery#8854, but the builds take a couple of hours to complete with the results we already have (+ I believe, the code needs rebasing, as the DuckDB version in the branch is stale).

However, looking at the issue it seems that the thing to look at is this:

1. Check that the produced file is able to be linked statically
2. Verify that the static linking is used instead of the dynamic one (dynamic may be somehow enforced for Go based on the CGO being used, as the __imp_ prefixes indicate an attempt to link against DLL instead of static linking).