Can no longer build on custom target

[dbeckwith]

The new build script to auto-detect i128 support fails on a custom target. Is i128 support a requirement to use this library now?

My project dependencies went from

num-rational = { version = "0.2.4", default-features = false }
num-traits = { version = "0.2.12", default-features = false, features = ["libm"] }

to

num-rational = { version = "0.3.0", default-features = false }
num-traits = { version = "0.2.12", default-features = false, features = ["libm"] }

which now causes this build error:

error: failed to run custom build command for `num-traits v0.2.12`

Caused by:
  process didn't exit successfully: `$PROJECT/target/debug/build/num-traits-9a6a769874348864/build-script-build` (exit code: 101)
  --- stderr
  error: Error loading target specification: Could not find specification for target "x86_64-snos". Use `--print target-list` for a list of built-in targets

  error: Error loading target specification: Could not find specification for target "x86_64-snos". Use `--print target-list` for a list of built-in targets

  warning: autocfg could not probe for `std`
  error: Error loading target specification: Could not find specification for target "x86_64-snos". Use `--print target-list` for a list of built-in targets

  thread 'main' panicked at 'i128 support was not detected!', $HOME/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/num-traits-0.2.12/build.rs:10:9
  stack backtrace:
     0: backtrace::backtrace::libunwind::trace
               at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
     1: backtrace::backtrace::trace_unsynchronized
               at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.46/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:217
    10: std::panicking::rust_panic_with_hook
               at src/libstd/panicking.rs:526
    11: std::panicking::begin_panic
               at $HOME/.rustup/toolchains/nightly-2020-07-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/panicking.rs:456
    12: build_script_build::main
               at ./build.rs:10
    13: std::rt::lang_start::{{closure}}
               at $HOME/.rustup/toolchains/nightly-2020-07-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/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:348
    16: std::panicking::try
               at src/libstd/panicking.rs:325
    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 $HOME/.rustup/toolchains/nightly-2020-07-06-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/rt.rs:67
    20: main
    21: __libc_start_main
    22: _start
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

[dbeckwith]

Ah, looking into num-rational more, I see in 0.3.0 it explicitly sets the i128 feature on num-traits and num-integer. I think there should be a way to turn off this feature so it can be usable on targets without i128 support.

[cuviper]

What version of rustc are you using? num-rational 0.3 requires at least 1.31.

[cuviper]

If you do have a new enough rustc, it may just be that the "Error loading target specification" is stopping us in our tracks, completely breaking autocfg. That is, your compiler probably does support i128, but we're failing to detect that. We could relax the num-traits build script to just assume it's okay when the feature is specified explicitly, but I think there will still be wider problems with autocfg in general.

How are you specifying the target spec? This may be akin to cuviper/autocfg#15.

[dbeckwith]

I'm using nightly-2020-07-06 to compile a custom target with this target spec:

{
  "llvm-target": "x86_64-unknown-none",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "arch": "x86_64",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": "32",
  "os": "none",
  "executables": true,
  "linker-flavor": "ld.lld",
  "linker": "rust-lld",
  "panic-strategy": "abort",
  "disable-redzone": true,
  "features": "-mmx,-sse,+soft-float"
}

I'm compiling for it using cargo-xbuild. I am using a .cargo/config file with these contents:

[build]
target = "x86_64-snos.json"

[target.'cfg(target_os = "none")']
runner = "bootimage runner"

[dbeckwith]

Hmm yeah looking more into how autocfg works, this may be tricky. Wouldn't it need to invoke rustc the same way I am, which is through cargo-xbuild and with various configuration options?

[dbeckwith]

Providing some mechanism to override its detection may be necessary, via feature flags maybe.

[cuviper]

I think we could relax this particular case -- when the "i128" feature is enabled, just use it without probing autocfg at all.