Post #2785551

@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.