3 ms·
I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make t
by lvh 10y ago
I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make this _easier_ for anyone who isn't writing like C or _maybe_ Rust and _maybe_ Go. (So, anything on the JVM, Python, Javascript, Ruby, PHP... You name it.)
For those use cases, the consumed artifact is a .so. Having a .so is easier than having to make it. Furthermore, having repeatedly built libsodium (I built FPM debs when libsodium wasn't yet commonly packaged), for those people building this is just as easy as libsodium if for some reason they need to build at all.
- loup-vaillant 10y ago> Having a .so is easier than having to make it. What's the point, a compilation unit is only a gcc call away from being an .so, right? Besides, I made sure I don't expose unnecessary symbols to the linker. What you're telling me amounts to saying binary distributions are easier to consume than source distributions. I would be quite bewildered by such a claim. As well as a little upset at my disadvantage: I do not have the resources to package my library for all major OSes and distributions. This of course has nothing to do with the library itself, merely the community around it (with one author and no user, as is the case with anything new). I've seen new programming languages being criticised for the immaturity of their tooling or the lack of community. This feels similar. --- Or, your idea of an .so is different from mine. Does .so libraries have something the C source files don't?