You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, most -sys crates, together with even libc, can't query if an external library contains a certain symbol or not. This makes it so these crates target a specific version of a library, instead of being able to adapt to changes in such libraries (for example libgit2-sys and the issues in rust-lang/libc#1848), unless one is using bindgen or similar.
I am aware this crate doesn't want to carry functionality for generating binaries or dynamic libraries (#46, #250, #458), but, as far as I know, those are the only two ways to make the linker check if all symbols can be resolved, which would in turn allow for "primitive" feature detection.
I'd like to use such a feature to implement rust-lang/libc#2088 (comment). Do you think it's feasible to build it atop cc-rs, or, given this justification, do you think cc-rs could carry it?
The text was updated successfully, but these errors were encountered:
fyi I maintain rsconf which has only cc-rs as a dependency and implements the functionality required for build scripts, such as target.has_symbol() or target.has_library(). We built this for use in fish-shell when we ported from C++ to rust over the past two years.
Unlike libc's "based off target-triple" approach, we feature detect specific libc features such as pipe2() or posix_spawn() so we can more gracefully handle older versions of the same system/architecture.
Hi!
As it stands, most
-sys
crates, together with evenlibc
, can't query if an external library contains a certain symbol or not. This makes it so these crates target a specific version of a library, instead of being able to adapt to changes in such libraries (for examplelibgit2-sys
and the issues in rust-lang/libc#1848), unless one is usingbindgen
or similar.I am aware this crate doesn't want to carry functionality for generating binaries or dynamic libraries (#46, #250, #458), but, as far as I know, those are the only two ways to make the linker check if all symbols can be resolved, which would in turn allow for "primitive" feature detection.
I'd like to use such a feature to implement rust-lang/libc#2088 (comment). Do you think it's feasible to build it atop
cc-rs
, or, given this justification, do you thinkcc-rs
could carry it?The text was updated successfully, but these errors were encountered: