many *-sys crates (bindings) compile own private version of library if the library is not found on the system. Often such dependencies are overlooked and can lead to automagic dependencies and breakage. Let's find and fix those type of bugs and make sure packages depend on system libraries.
Given what I've seen with similar things in Perl space, I'd think it pertinent in some cases to have a USE="system-foo" flag in various places, and then: - If the use is not specified, *always* use the bundled copy - If the use is specified, *always* use the system copy Partly because the system dependency can change not only A[B]I, but A[P]I, and as a result, can break tests, and dependent logic. And then we can set the default USE to whatever is the most reliable, and allow puritans to flip the system- flag if they'd rather. Also, the API dependency can be a very narrow version range ( eg: an == dep ), and this can severely mess up portage's capacity to handle things. And ... to make matters worse, there can be a known minimum version at the time of publication, but the maximum supported version might not be known until much, much later. ( Making == over-specific, but > underspecific )
know crates to use bundled lib by default unless instructed to use system one: > libgit2-sys // dev-libs/libgit2-0.99:= requires setting export PKG_CONFIG_ALLOW_CROSS=1 and export LIBGIT2_SYS_USE_PKG_CONFIG=1 to force usage of system version for quite a long time used private apis from git version, not available in 0.28 yet. slot 0/1.0 is fine with current crate versions. > libssh2-sys // net-libs/libssh2:= export LIBSSH2_SYS_USE_PKG_CONFIG=1 PKG_CONFIG_ALLOW_CROSS=1 > jemalloc-sys-0.3.2 // >=dev-libs/jemalloc-5.1.0:= || comes with jemallocator crate requires setting > use elibc_musl || export JEMALLOC_OVERRIDE="${ESYSROOT}/usr/$(get_libdir)/libjemalloc.so"
another one is oniguruma-sys. will update sys-apps/bat to use system version and will update details here how to do it properly.
another point about -sys crates -lto flags will produce a falure. see bugs #730252 #730254
> export RUSTONIG_SYSTEM_LIBONIG=1 was required for onig-sys to use system library in sys-apps/bat
another offender, serious one openssl-sys sometimes needs > export OPENSSL_NO_VENDOR=true to stop compiling private copy
(In reply to Georgy Yakovlev from comment #4) > another point about -sys crates > > -lto flags will produce a falure. > see bugs #730252 #730254 Is there common way or recommended Gentoo way to avoid LTO (especially `CFLAGS=-flto`) issues? I think `CFLAGS+=-fno-lto` is possible workaround, but is it recommended to prepare `USE=system-foo`? -------- Other packages (I'm the maintainer of these ebuilds) that fail to compile due to (maybe) LTO: - media-gfx/oxipng-5.0.1::guru (#860063) + Fails with `CFLAGS=-flto`, and compiles with `CFLAGS=-fno-lto`. + `libdeflate-sys` crate? - media-gfx/silicon-0.4.3::guru (#860069) + Fails with `CFLAGS=-flto`, and compiles with `CFLAGS=-fno-lto`. + `onig_sys` crate? And the below (not by me) also seems to fail with the same reasons: - dev-util/cargo-audit-0.17.0 (#858323) + `libgit2-sys` crate? - dev-util/cargo-c-0.9.9 (#858329) + `libgit2-sys` crate? - dev-util/cargo-ebuild-0.5.1 (#858332) + `libgit2-sys` crate?
Setting LIBGIT2_SYS_USE_PKG_CONFIG=1 to force the system library for libgit2-sys is no longer necessary since libgit2-sys-0.12.2. Having a library installed which satisfies the version range (>=1.6.4 <1.7 as of 06-2023) suffices.
<zstd-sys-2.0.7 > --feature "pkg-config" zstd-sys-2.0.7 and up > --feature "pkg-config" || export ZSTD_SYS_USE_PKG_CONFIG=1
I've put some workarounds on the wiki for visibility. https://wiki.gentoo.org/wiki/Writing_Rust_ebuilds#Unbundling_C_libraries
