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

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

Open
stefson opened this issue Aug 8, 2020 · 2 comments

Comments

@stefson
Copy link
Contributor

stefson commented Aug 8, 2020

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

stefson commented Aug 9, 2020

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

stefson commented Aug 27, 2021

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.

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

No branches or pull requests

1 participant