5 ms·

What was particularly difficult about it? Sometimes modifying someone else's code to build statically or on another platform is tricky. Linking is generally jus

by carom 2y ago

What was particularly difficult about it? Sometimes modifying someone else's code to build statically or on another platform is tricky. Linking is generally just include dir, lib path, and lib though.

lairv 2y ago
The library was duckdb (https://duckdb.org/docs/installation/ 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
- jpc0 2y ago
  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.
  - oconnor663 2y ago
    > 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.
  - lairv 2y ago
    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
    - jpc0 2y ago
      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.
      - jodrellblank 2y ago
        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.
        jpc0 2y ago
        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.
    - jpc0 2y ago
      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 https://duckdb.org/docs/api/cpp
  - tdullien 2y ago
    I have seen way more projects with very broken CMake integration than rust packages with broken cargo setup. CMake is a pain.
- lr1970 2y ago
  > 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 ?
  - lairv 2y ago
    That was a typo, the file was duckdb_static.a
- carom 2y ago
  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!
  - eddd-ddde 2y ago
    So you stopped using a tool because someone misspelled a word?
    - carom 2y ago
      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.

by carom 2y ago

lairv 2y ago

The library was duckdb (https://duckdb.org/docs/installation/ 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

jpc0 2y ago
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.
- oconnor663 2y ago
  > 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.
- lairv 2y ago
  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
  - jpc0 2y ago
    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.
    - jodrellblank 2y ago
      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.
      - jpc0 2y ago
        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.
  - jpc0 2y ago
    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 https://duckdb.org/docs/api/cpp
- tdullien 2y ago
  I have seen way more projects with very broken CMake integration than rust packages with broken cargo setup. CMake is a pain.
lr1970 2y ago
> 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 ?
- lairv 2y ago
  That was a typo, the file was duckdb_static.a
carom 2y ago
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!
- eddd-ddde 2y ago
  So you stopped using a tool because someone misspelled a word?
  - carom 2y ago
    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.