Open indygreg opened 3 years ago
Isn't the problem that you have musl-gcc installed but you don't have a musl toolchain (with musl headers) installed?
right shift count >= width of type
This indicates to me that the musl headers you are using are 64 bit but the compiler is compiling in 32-bit mode.
What you're doing probably works with clang but not GCC. See below:
if (target.arch == "wasm32" && target.os == "unknown")
|| (target.os == "linux" && is_musl && target.arch != "x86_64")
{
if let Ok(compiler) = c.try_get_compiler() {
// TODO: Expand this to non-clang compilers in 0.17.0 if practical.
if compiler.is_like_clang() {
let _ = c.flag("-nostdlibinc");
let _ = c.define("RING_CORE_NOSTDLIBINC", "1");
}
}
}
Does GCC support -nostdlibinc
? Or does it support something that can do the same? If so, it would be great if you could submit a PR with something that works for GCC.
@indygreg Did you get this working? Is this still an issue for you?
Just FYI, I have the same issue and didn't find a workaround yet.
Not too important, I could just compile natively instead of cross-compiling. However, a proper solution would be more convenient.
It seems like -nostdlibinc
is not supported by gcc
.
This looks like there is a fundamental problem with musl-gcc -m32
.
Compiling this:
#include <stdint.h>
#include <assert.h>
static_assert(sizeof(uint32_t) == 4, "what???");
static_assert(sizeof(uint64_t) == 8, "what???");
With musl-gcc -m32 t.c
results in:
t.c:4:1: error: static assertion failed: "what???"
static_assert(sizeof(uint64_t) == 8, "what???");
^~~~~~~~~~~~~
It's no surprise that a 32bit uint64_t breaks things.
It's no surprise that a 32bit uint64_t breaks things.
AFAICT, when this happens, this means that the headers are mismatched to what the compiler expects.
I have found that clang works much more reliably for cross-compiling than gcc.
If people think it is super important to support musl-gcc we could switch CI/CD to use musl-gcc instead of clang for this target, I guess.
Is there any way I could try to give clang a try?
As a workaround, it kinda' works on Ubuntu 18.04, see https://github.com/briansmith/ring/issues/1507.
I get a similar error and can't figure out how to solve it
--- stdout
OPT_LEVEL = Some("3")
TARGET = Some("i686-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
cargo:rerun-if-env-changed=CC_i686-unknown-linux-musl
CC_i686-unknown-linux-musl = None
cargo:rerun-if-env-changed=CC_i686_unknown_linux_musl
CC_i686_unknown_linux_musl = None
cargo:rerun-if-env-changed=TARGET_CC
TARGET_CC = Some("musl-gcc")
cargo:rerun-if-env-changed=CFLAGS_i686-unknown-linux-musl
CFLAGS_i686-unknown-linux-musl = None
cargo:rerun-if-env-changed=CFLAGS_i686_unknown_linux_musl
CFLAGS_i686_unknown_linux_musl = None
cargo:rerun-if-env-changed=TARGET_CFLAGS
TARGET_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("crt-static,fxsr,sse,sse2")
--- stderr
running "musl-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m32" "-static" "-march=i686" "-Wl,-melf_i386" "-I" "include" "-Wall" "-Wextra" "-std=c1x" "-Wbad-function-cast" "-Wnested-externs" "-Wstrict-prototypes" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-g3" "-U_FORTIFY_SOURCE" "-DNDEBUG" "-c" "-o/home/user/my_app/target/i686-unknown-linux-musl/release/build/ring-417329f1ff283af4/out/montgomery.o" "crypto/fipsmodule/bn/montgomery.c"
In file included from crypto/fipsmodule/bn/montgomery.c:109:
crypto/fipsmodule/bn/internal.h: In function ‘bn_umult_lohi’:
crypto/fipsmodule/bn/internal.h:193:33: warning: right shift count >= width of type [-Wshift-count-overflow]
193 | *high_out = (BN_ULONG)(result >> BN_BITS2);
| ^~
In file included from crypto/fipsmodule/bn/montgomery.c:113:
crypto/fipsmodule/bn/../../limbs/limbs.inl: In function ‘limb_adc’:
crypto/fipsmodule/bn/../../limbs/limbs.inl:66:19: warning: right shift count >= width of type [-Wshift-count-overflow]
66 | ret = (Carry)(x >> LIMB_BITS);
| ^~
crypto/fipsmodule/bn/../../limbs/limbs.inl: In function ‘limb_add’:
crypto/fipsmodule/bn/../../limbs/limbs.inl:80:19: warning: right shift count >= width of type [-Wshift-count-overflow]
80 | ret = (Carry)(x >> LIMB_BITS);
| ^~
crypto/fipsmodule/bn/../../limbs/limbs.inl: In function ‘limb_sbb’:
crypto/fipsmodule/bn/../../limbs/limbs.inl:96:20: warning: right shift count >= width of type [-Wshift-count-overflow]
96 | ret = (Carry)((x >> LIMB_BITS) & 1);
| ^~
crypto/fipsmodule/bn/../../limbs/limbs.inl: In function ‘limb_sub’:
crypto/fipsmodule/bn/../../limbs/limbs.inl:110:20: warning: right shift count >= width of type [-Wshift-count-overflow]
110 | ret = (Carry)((x >> LIMB_BITS) & 1);
| ^~
In file included from include/GFp/base.h:59,
from crypto/fipsmodule/bn/internal.h:126:
crypto/fipsmodule/bn/montgomery.c: At top level:
include/GFp/type_check.h:71:42: error: static assertion failed: "uint64_t is insufficient precision for n0"
71 | #define OPENSSL_STATIC_ASSERT(cond, msg) _Static_assert(cond, msg)
| ^~~~~~~~~~~~~~
crypto/fipsmodule/bn/montgomery.c:117:1: note: in expansion of macro ‘OPENSSL_STATIC_ASSERT’
117 | OPENSSL_STATIC_ASSERT(
| ^~~~~~~~~~~~~~~~~~~~~
thread 'main' panicked at 'execution failed', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/build.rs:656:9
I'm a bit new at this, so please forgive me. Really hoping for some help)
If I attempt to cross-compile from an x86-64 Linux host to a
i686-unknown-linux-musl
target using Ubuntu 21.04, I get the following error:I can build ring fine in Docker images that have more flushed out musl toolchains that aren't as sensitive to cross-compiling issues. Most Rust crates can cross-compile to musl targets just fine. My guess is this C code / build system isn't sniffing out target features sufficiently.
This seems like a minor issue and is easy enough to workaround by switching build environments.