smaeul / portage-overlay

Extra ebuilds for Gentoo systems, mostly packages fixed to work with musl
18 stars 2 forks source link

dev-lang/rust: on armv7-unknown-linux-musleabihf the neonthumbv7 target cannot be configured #24

Open stefson opened 4 years ago

stefson commented 4 years ago

cpu_flags_arm_thumbv2 is masked:

musl-box / # emerge -pv =rust-1.41.1

These are the packages that would be merged, in order:

[ebuild U #] dev-lang/rust-1.41.1:stable/1.41::musl [1.34.2:stable/1.34::musl] USE="-clippy -debug -doc -libressl -miri% -nightly% -parallel-compiler% -rls -rustfmt -system-bootstrap% -system-llvm -wasm%" CPU_FLAGS_ARM="neon% (-thumb2)" LLVM_TARGETS="(ARM) -AArch64 -AMDGPU -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV% -Sparc -SystemZ -WebAssembly -X86 -XCore" 0 KiB

and with only cpu_flags_arm_neon available there's nothing happening during src_configure:

[llvm]
optimize = true
release-debuginfo = false
assertions = false
ninja = true
targets = "ARM"
experimental-targets = ""
link-shared = false
[build]
build = "armv7a-unknown-linux-musleabihf"
host = ["armv7a-unknown-linux-musleabihf"]
target = ["armv7a-unknown-linux-musleabihf","armv7-unknown-linux-musleabihf"]
cargo = "/var/tmp/portage/dev-lang/rust-1.41.1/work/rust-stage0/bin/cargo"
rustc = "/var/tmp/portage/dev-lang/rust-1.41.1/work/rust-stage0/bin/rustc"
docs = false
compiler-docs = false
submodules = false
python = "python3.7"
locked-deps = true
vendor = true
extended = true
tools = ["cargo"]
verbose = 2
sanitizers = false
profiler = false
cargo-native-static = false
[install]
prefix = "/usr"
libdir = "lib"
docdir = "share/doc/rust-1.41.1"
mandir = "share/man"
[rust]
optimize = true
debug = false
debug-assertions = false
debuginfo-level-rustc = 0
backtrace = true
incremental = false
default-linker = "armv7a-unknown-linux-musleabihf-gcc"
parallel-compiler = false
channel = "stable"
rpath = false
verbose-tests = true
optimize-tests = true
codegen-tests = true
dist-src = false
lld = false
backtrace-on-ice = true
jemalloc = false
[dist]
src-tarball = false
[target.armv7a-unknown-linux-musleabihf]
cc = "armv7a-unknown-linux-musleabihf-gcc"
cxx = "armv7a-unknown-linux-musleabihf-g++"
linker = "armv7a-unknown-linux-musleabihf-gcc"
ar = "armv7a-unknown-linux-musleabihf-ar"
crt-static = false
[target.armv7-unknown-linux-musleabihf]
cc = "armv7a-unknown-linux-musleabihf-gcc"
cxx = "armv7a-unknown-linux-musleabihf-g++"
linker = "armv7a-unknown-linux-musleabihf-gcc"
ar = "armv7a-unknown-linux-musleabihf-ar"
crt-static = false
stefson commented 4 years ago

the double generated target.armv7(a) in the config.toml might be from an error in the false detection of armv7a-unknown-linux-musleabihf as multilib?

stefson commented 3 years ago

first problem can be solved by unmasking thumb2 mask, and also I believe to have found the line which causes the double entry of armv7+armv7a. Right now the patched up ebuild still compiles, but config.toml seemed to be okay. Will publish diff file in the next days.