Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can no longer build on custom target #177

Closed
dbeckwith opened this issue Jul 7, 2020 · 7 comments · Fixed by #185
Closed

Can no longer build on custom target #177

dbeckwith opened this issue Jul 7, 2020 · 7 comments · Fixed by #185

Comments

@dbeckwith
Copy link

dbeckwith commented Jul 7, 2020

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/github.com-1ecc6299db9ec823/num-traits-0.2.12/build.rs:10:9
  stack backtrace:
     0: backtrace::backtrace::libunwind::trace
               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
     1: backtrace::backtrace::trace_unsynchronized
               at /cargo/registry/src/github.com-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
Copy link
Author

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
Copy link
Member

cuviper commented Jul 7, 2020

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

@cuviper
Copy link
Member

cuviper commented Jul 7, 2020

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@cuviper
Copy link
Member

cuviper commented Jul 8, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants