Details
- Reviewers
pizzamig - Group Reviewers
O5: Ports Framework (Owns No Changed Paths) portmgr - Commits
- rP472373: Mk/Uses/cargo.mk: Encode more crate build dependencies
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 16647 Build 16552: arc lint + arc unit
Event Timeline
Mk/Uses/cargo.mk | ||
---|---|---|
145 | Hmm, not sure. The onig_sys build script is like this: https://github.com/rust-onig/rust-onig/blob/v3.2.2/onig_sys/build.rs#L126 So I don't think RUSTONIG_DYNAMIC_LIBONIG would ever be used when it can find oniguruma >= 6.8.0 on the system. With RUSTONIG_SYSTEM_LIBONIG bat definitely links with libonig.so: [111amd64-default-job-03] Installing bat-0.3.0_1... =========================================================================== =>> Checking shared library dependencies 0x0000000000000001 NEEDED Shared library: [libc.so.7] 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] 0x0000000000000001 NEEDED Shared library: [libm.so.5] 0x0000000000000001 NEEDED Shared library: [libonig.so.5] 0x0000000000000001 NEEDED Shared library: [libthr.so.3] 0x0000000000000001 NEEDED Shared library: [libz.so.6] Maybe both should be defined? |
Mk/Uses/cargo.mk | ||
---|---|---|
145 | IMHO, neither are currently strictly needed, but probably you're right and RUSTONIG_SYSTEM_LIBONIG is the way to go, to be on the safe side. I've tested onig-sys with zero, one or both variables and the result was always the same, because the system library is preferred, if found, and the static library, that would be the default, is missing from devel/oniguruma, so the dynamic one is used. |
Mk/Uses/cargo.mk | ||
---|---|---|
145 | Thanks. I've added a comment to cargo.mk about this. |
Mk/Uses/cargo.mk | ||
---|---|---|
132–134 | Mmm, the two :M are not the same, if there is a libc.0.1.something, it won't show up in the warning. |
CC @0mp because libc warning affects games/genact.
Mk/Uses/cargo.mk | ||
---|---|---|
133 | "issues" are mainly crashes but if not they'd be hard to detect. libc crate "supports" 64-bit inodes and absolute kevent(2) timeouts since 0.2.38. rP468993 simply standardized on the latest version to facilitate debugging and pick up other FreeBSD fixes. | |
134 | 12.0-CURRENT will be obsolete in half a year and contributor may confuse libc with base system package. See also existing DEV_WARNING style under Mk/. Maybe try: .if ${CARGO_CRATES:Mlibc-[0-9]*} # FreeBSD 12.0 changed ABI: r318736 and r320043 # https://github.com/rust-lang/libc/commit/78f93220d70e # https://github.com/rust-lang/libc/commit/969ad2b73cdc _libc_VER= ${CARGO_CRATES:Mlibc-[0-9]*:C/.*-//} . if ${_libc_VER:R:R} == 0 && (${_libc_VER:R:E} < 2 || ${_libc_VER:R:E} == 2 && ${_libc_VER:E} < 38) DEV_WARNING+= "CARGO_CRATES=libc-0.2.37 or older maybe unstable on FreeBSD 12.0. Consider updating to the latest version." . endif .undef _libc_VER .endif |