Hacker News Reader

Comment by lairv | Hacker News Reader

The library was duckdb (https://duckdb.org/docs/installation/), and here are some of the issues I ran into:

- trying to compile against the prebuilt duckdb_static.so file got me a ton of undefined reference error, I asked about this on their discord and it seems to be a knwon issue, there are additional dependencies that are not part of the release so I had to build it myself

- the library uses CMake but it contains a Makefile and they recommend using that to build it

- It seems like on windows, if you create a dynamic library you have to add __declspec(dllexport) before each function. DuckDB has a #ifdef DUCKDB_STATIC_BUILD to toggle/disable it which isn't documented anywhere, you have to read the code

I'm sure someone will tell me that this is very standard and shouldn't take me 3 days to figure it out, but with basic knowledge of cmake and build systems that's a bit of a pain, and there's no other language where you have to do that

View on HN

> trying to compile against the prebuilt duckdb_static.so

Typically you statically link against .a object library. .so are shared objects intended for dynamical linking only. Does duckdb provide something like duckdb.a ?

That was a typo, the file was duckdb_static.a

Ha, I used duckdb once and ran into a memory corruption issue through normal usage. It was a known issue also surfaced by a fuzzer. One of the devs referred to the fuzzer as the fusser in the issue about it and I stopped using the project immediately. Best of luck with that one!

So you stopped using a tool because someone misspelled a word?

I stopped using it because it was in a memory unsafe language, had readily triggered crashes, and because a developer seemed to security as a chore.

CMake, the defacto if not standard build system, when correctly setup, does all this for you.

Your argument is along the lines of "the maintainer of X rust package didn't setup cargo correctly and it's impossible to include in my project, rust is a horrible language". You can absolutely make an argument that the lack of a standard build system is a pain point, and well it's C++ you get to be a special snowflake and use a makefile instead of CMake but then the onus is on you to provide correct documentation.

In the case of duckdb they provide proper packages for pip, cargo, npm, go get, and the only one that seems like a PITA to use is the C/C++ dependencies, even though the package is written is C++, so I think this tells something about C++ dependency management

You seem to be agreeing with me then, weird take to do it while sounding like you disagree...

As I said, you can make the argument C++ build systems are no good. However the argument originally made is that C++ the language caused these issues when in reality the package maintainer hasn't put in the effort to properly document and fix known issues in their chosen build system for C++.

The fact that they in fact have built out proper packages for pip, cargo, npm and go tells me they have the necessary expertise on the team and made an active choice to not do the same for C++. Create an issue with the maintainer.

The argument originally made was "You can read front-to-cover books about every details of C++ semantics and it'll still be a PITA to work on real world projects"

Which is not disagreeing with you just because you are explaining/disputing the reason it was a PITA.

That statment was qualified by:

> While I'm far from a cmake/cpp expert, this is a non-issue with most modern languages: you just pip install, cargo add, npm install, go get etc.

Which I also find fundamentally wrong because most real world projects have a C/C++ dependency which needs to be built and is built from one of those languages build systems by calling into cmake / autotools + make.

Just because you called apt-get or any other way to pull dependencies doesn't remove the fact that they need to be built and likely involve a C compiler.

Seeing as it's Christmas Eve and I has nothing better to do...

Duckdb own documentation says the C++ API is internal and you should use the C API[1]

The makefile also has a 'bundle-library' option which seems to be exactly what you were looking for, it generates a statically linked library which is what the Golang package is using, probably others too but that's the one I checked first.

This is purely a documentation problem, the build system does what is needed it seems. Create an issue, or better yet, add the necessary documentation...

1. https://duckdb.org/docs/api/cpp

I used the C api but I did miss the 'bundle-library' option, will look into that

I definitely don't blame you for missing it.

I found it by looking at the go package because they claimed they are statically linking there.

> the maintainer of X rust package didn't setup cargo correctly and it's impossible to include in my project

That basically never happens, which is the point.

I have seen way more projects with very broken CMake integration than rust packages with broken cargo setup.

CMake is a pain.

Reply on news.ycombinator.com