Post #2785540
2026-03-31 15:34 UTC
Replies (5)
-
@sgued@pouet.chapril.org 2026-03-31 15:40
@ekuber@hachyderm.io How would go for C dependencies that are meant to be statically linked and not really packaged ? Asking seriously as a maintainer of the littlefs2-sys crate used in bare-metal embedded, I wish we had a better option that just having it as a git submodule.
-
@piecritic@hachyderm.io 2026-03-31 15:45
@ekuber@hachyderm.io I disagree. I care a lot more about portability of binaries than the other tradeoffs. That said, I do not vendor the C/C++ code, it's almost always a git subtree or submodule depending on use case. The reason is that I put a great deal of effort into making sure that the library builds for all desktop and mobile operating systems statically (which is a fun surgical operation for Windows half the time). In the case where it's sensible to allow using the system library, that's an env var opt-in. To put this discussion differently: I think that cargo doesn't cater for this use case particularly well and there's an open design space here that could satisfy both of our views without conflicting with either. :D
-
@weiznich@social.weiznich.de 2026-03-31 17:17
@ekuber@hachyderm.io I have opinions about this… I agree with you that using the system version of a C library is usually the better solution, but implementing this is currently rather painful in rust. Specifically this part: Instead they should attempt to use the system one and bail if that fails, with an error asking people to enable a feature flag to use the vendored dependency. is really hard to do correctly in a platform independent way. *-sys crates currently can use various strategies to find system dependencies: Asking the user to set an environment variable pointing to the correct library, which is painful to manage for the user as they need to set this for each *-sys crateUsing something like pkg-config to query the system about details of the library. This works reasonably well on standard linux/macos systems, but doesn't work anywhere else. (Especially not on windows…)Just set linker flags and pray that it will somehow work, which often works for reasonably configured system, but fails on systems where users set up stuff for developing the first time. (So it doesn't really work for new users unused to this kind of configuration, which is bad for obvious reasons). Most *-sys crates I'm aware of use all three strategies in combination, with one overwriting the other. The bad thing about that is that the failure mode isn't: We did not find that library, but it's The linker emits a wall of text about undefined symbols. That's again really bad for new users. On the other hand that's likely something that the rust compiler itself could improve, e.g. by post-processing the linker output. I remember Pietro showed something along that line last year in Utrecht. In addition to anything mentioned above there are other problems with system libraries. E.g. they might have different versions with different feature sets that need to be taken care of. That also might require different bindings for different versions. Or even such drastic things like a linux distribution "suddenly" starts shipping libxyz instead of libabc and just declares them compatible, although they are different. That happened with libmysqlclient vs libmariadb, which have mostly the same API and implement the same functionality but have different names and different behaviour and minor API differences in detail. Overall I think there are certain points that could be improved in the ecosystem like better linker error messages better version to generally query for system libraries as crate under the rust-project, but I don't think this ever will cover all edge cases. I would go even as far and state that I would be surprised if it can cover all use cases for the top 100 *-sys crates or so.
-
@cursedcode@hachyderm.io 2026-03-31 18:11
@ekuber@hachyderm.io I do wish Cargo.toml's had a way of declaring dependencies on "imported" libraries from other dependency providers.
-
@michalfita@mastodon.social 2026-04-01 17:59
@ekuber@hachyderm.io This is Catch 22 with where the trade off is going. Correct dependency on system libraries is usually target dependent, often even distro dependent - can maintainer afford the cost of keeping the compatibility? Or can deliver library that works on all? There's certain advantage with `cargo` as installed packages manager (could be better aligned to that), as it allow to keep tool installed outside the system scope. It's my preferred way, but you have to learn to live with that.