GitHub user zeroshade added a comment to the discussion: CGO dependency as adoption blocker for C++ engines
> * Extra Go toolchain in an already complex C++ build system > * Cross-compilation and static linking headaches Another question I have is that the point of using ADBC, like ODBC before it, is so that you *don't* have to statically link the driver in. Instead you would use the `AdbcDriverManager` and then just load the driver on the fly so that you can work with any driver instead of being tied to only a single one. Is there a reason you're trying to include the Go Snowflake ADBC driver in your build process rather than just treating the .so as a black box to dynamically load by pulling it from a release? (either by `dbc` or by a Github release, etc.) GitHub link: https://github.com/apache/arrow-adbc/discussions/4156#discussioncomment-16383411 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
