Cargo build fail with cargo installed by yum

[APIPLM]

cargo build
Updating crates.io index
Compiling version_check v0.9.2
Compiling const_fn v0.4.1 (/root/const_fn-master)
error: failed to run custom build command for const_fn v0.4.1 (/root/const_fn-master)

Caused by:
process didn't exit successfully: /root/const_fn-master/target/debug/build/const_fn-13eda46b8fb9e1dc/build-script-build (exit code: 101)
--- stdout
cargo:rustc-cfg=const_fn_has_build_script

--- stderr
thread 'main' panicked at 'unexpected output from rustc --version', build.rs:8:17
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /builddir/build/BUILD/rustc-1.45.2-src/vendor/backtrace/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /builddir/build/BUILD/rustc-1.45.2-src/vendor/backtrace/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1076
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1537
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:218
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:486
11: std::panicking::begin_panic
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/panicking.rs:410
12: build_script_build::main
at ./build.rs:8
13: std::rt::lang_start::{{closure}}
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/rt.rs:67
14: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:52
15: std::panicking::try::do_call
at src/libstd/panicking.rs:297
16: std::panicking::try
at src/libstd/panicking.rs:274
17: std::panic::catch_unwind
at src/libstd/panic.rs:394
18: std::rt::lang_start_internal
at src/libstd/rt.rs:51
19: std::rt::lang_start
at /builddir/build/BUILD/rustc-1.45.2-src/src/libstd/rt.rs:67
20: main
21: __libc_start_main
22:

[taiki-e]

Hmm, I'm not sure what is happening... I run CI on Rust 1.45.2 in #25 and it compiles successfully. Also it compiles successfully on my laptop.

[taiki-e]

thread 'main' panicked at 'unexpected output from rustc --version', build.rs:8:17

This error occurs only when version_check::triple() returns None:

const_fn/build.rs

Lines 6 to 9 in edb58a4

	let version = match Version::new() {
	Some(version) => format!("{:#?}\n", version),
	None => panic!("unexpected output from `rustc --version`"),
	};

const_fn/build.rs

Lines 23 to 25 in edb58a4

	impl Version {
	fn new() -> Option<Self> {
	let (version, channel, _date) = version_check::triple()?;

So, this error may actually mean that version_check is failing to run rustc or to parse it. (I don't feel it's a bug in their parser because I've successfully parsed the same version in other environments.)

[taiki-e]

@APIPLM
I don't know the exact way to fix this, but there are possibilities that you can fix it in the following ways:

• Remove build artifacts (i.e., run cargo clean)
• Stop uses of compiler caching tool if you used (e.g., sccache) (found crate version_check compiled by an incompatible version of rustc SergioBenitez/version_check#15)
• Use later version of Rust (It may be a bug in an older version of rustc or cargo)

If you can't solve it, it might be useful for debugging if you can provide the following information:

• Output of rustc --version.
• Version of OS.
• Whether it can be reproduced with other versions of Rust.

[APIPLM]

@taiki-e Thanks for your help. you are right. It is about Rustc and Cargo version and it works for version 1.46.0.In my side, I have backup VM machine, which has the almost same version of CentOS( the original one having patch 3.10.0-1127.19.1 , the backup 3.10.0-1127.13.1) and GCC same version which is (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) . In the backup machine, I reference to like install rust on archlinux( https://wiki.archlinux.org/index.php/Rust). In the original one. I just installed all packages by yum (like yum install Rust-x86-64, Rust-src, rust-std-static and so on). Then on the original one, the rustc version is 1.45.2 and cargo version is 1.45.1, and on the backup one, the rustc version is 1.46.0 and the cargo version is 1.46.0. I was wondering why there are people put the old version in the repo for Centos. But the point is how yum and rpm work like what cargo of rust have for package manager. If something is incorrect from my side. Point out, please. Thanks in advance.

[APIPLM]

@taiki-e As go further to build time-main(version "0.2.16" https://github.com/time-rs/time). The below error come out. Seem like related to const_fn
Running rustc --crate-name time --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -Cembed-b itcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="deprecated"' --cfg 'feature="libc"' --cfg 'feature="std"' --cfg 'feature="stdweb"' --cfg 'feature="winapi "' -C metadata=61a653f1280f4071 -C extra-filename=-61a653f1280f4071 --out-dir /root/time-main/target/debug/deps -C incremental=/root/time-main/target/debug/incremental -L d ependency=/root/time-main/target/debug/deps --extern cfg_if=/root/time-main/target/debug/deps/libcfg_if-748f21f0c8637ed0.rmeta --extern const_fn=/root/time-main/target/debu g/deps/libconst_fn-c998fcebd195f88b.so --extern libc=/root/time-main/target/debug/deps/liblibc-3b067de2f719f3b2.rmeta --extern standback=/root/time-main/target/debug/deps/l ibstandback-6cba24141a007cb4.rmeta --extern time_macros=/root/time-main/target/debug/deps/libtime_macros-297d54a75eca283c.rmeta --cfg __time_02_supports_non_exhaustive --cf g __time_02_instant_checked_ops --cfg __time_02_nonzero_signed --cfg __time_02_use_trait_as_underscore
error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:622:36
|
622 | let mut seconds = try_opt!(self.seconds.checked_add(rhs.seconds));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:627:32
|
627 | seconds = try_opt!(seconds.checked_add(1));
| ^^^^^^^^^^^^^^^^^^^^^^

error: core::num::<impl i64>::checked_sub is not yet stable as a const fn
--> src/duration.rs:630:32
|
630 | seconds = try_opt!(seconds.checked_sub(1));
| ^^^^^^^^^^^^^^^^^^^^^^

error: core::num::<impl i64>::checked_mul is not yet stable as a const fn
--> src/duration.rs:678:31
|
678 | try_opt!(try_opt!(self.seconds.checked_mul(rhs as i64)).checked_add(extra_secs));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: core::num::<impl i64>::checked_add is not yet stable as a const fn
--> src/duration.rs:678:22
|
678 | try_opt!(try_opt!(self.seconds.checked_mul(rhs as i64)).checked_add(extra_secs));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 5 previous errors

error: could not compile time.

[taiki-e]

In the backup machine, I reference to like install rust on archlinux( https://wiki.archlinux.org/index.php/Rust). In the original one. I just installed all packages by yum (like yum install Rust-x86-64, Rust-src, rust-std-static and so on).

I think it's likely that the rustc or cargo provided by the vendor is a little broken.
I would suggest making sure rustup update 1.45.2 && cargo +1.45.2 build works well on the backup machine that installed rust by rustup.
If that succeeds, by uninstalling rust installed by yum once & reinstalling rust by rustup, then it should probably compile fine even with 1.45.2 on the original machine.

[jhpratt]

@APIPLM That's an error on my end, and is a failure that isn't the fault of this crate. I believe I already pushed up a newer commit that fixed it, but if not it's in my laptop.

[APIPLM]

@taiki-e you are right. in backup one after rustup update 1.45.2 and set to it as an active channel.
it is still working. it is about installing toolchain(rustc, cargo and so on) by rustup. And also before running "cargo build", make sure it is clean, and run cargo clean and also removed its dependence version_check-0.9.2.crate in the folder /root/.cargo/registry/cache/github.jparrowsec.cn-1ecc6299db9ec823 and the src version_check-0.9.2.rs in the folder /root/.cargo/registry/src/github.jparrowsec.cn-1ecc6299db9ec823

In the original machine, uninstalled rust installed by yum and install rust 1.45.2 by rustup. then there is no issue as compiling the const_fn-master. of course removed cache version_check-0.9.2.crate and version_check-0.9.2.rs. I was wondering what happened as rustup install rust 1.45.2 and yum install rust.x86_64. I think that we can close this issue.

[APIPLM]

@jhpratt Thanks, as I said that that issue might related to this crate when seeing the message like "error: core::num::::checked_add is not yet stable as a const fn". As running cargo build on rustc 1.45.2 and cargo 1.45.1, it work fine for time 0.2.16. But running cargo build on rustc 1.46.0 and cargo 1.46.0 (stable version) for times 0.2.16 and there is the issue as I posted in the above. And also in the code level, I can see you that you mentioned that "This function is const fn when using rustc >= 1.46." and but it not like that.Same like as you said you might have not commit the latest code to repo ,but the comment in the source code already mentioned that.

@taiki-e if you have any comments. Feel freely to say. Thanks in advance.

[taiki-e]

As said in #26, I believe this issue is completely resolved so I'll close this.

[taiki-e]

(Marked as a (fixed) bug. It's likely that version_check failed to determine the version because the linux vendor added some extra strings to the version info, but we fixed them by improving the parser. I'll update the changelog of v0.4.2 to mention about this.)

[APIPLM]

@jhpratt you are right. that issue is not related to this one. As I checked out the latest time-rs(0.2.18),then built in the rustc 1.46.0, there is not the issue as I said in the above.