Upgrading old system from 17.0 musl to 23.0 profile. As a first step, I'm running emerge -avuUDN @world before proceeding with the profile instructions, and maturin comes as a dependency. = note: /usr/lib/gcc/x86_64-gentoo-linux-musl/12/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lssl: No such file or directory /usr/lib/gcc/x86_64-gentoo-linux-musl/12/../../../../x86_64-gentoo-linux-musl/bin/ld: cannot find -lcrypto: No such file or directory collect2: error: ld returned 1 exit status Reproducible: Always Steps to Reproduce: 1. emerge maturin 2. 3.
Created attachment 901792 [details] emerge --info '=dev-util/maturin-1.7.0::gentoo'
# emerge -pqv '=dev-util/maturin-1.7.0::gentoo' [ebuild N ] dev-util/maturin-1.7.0 USE="ssl -debug -doc -test" PYTHON_TARGETS="python3_12 (-pypy3) -python3_10 -python3_11 (-python3_13)"
Created attachment 901793 [details] build.log
Rust is pretty recent and obviously openssl is present on the system (but not openssl-compat): # eix -e rust * dev-lang/rust Available versions: (stable) ~1.71.0(stable/1.71)^t 1.71.1(stable/1.71)^t ~1.73.0(stable/1.73)^t 1.74.1(stable/1.74)^t 1.75.0-r1(stable/1.75)^t ~1.76.0-r1(stable/1.76)^t 1.77.1(stable/1.77)^t ~1.78.0(stable/1.78)^t 1.79.0(stable/1.79)^t ~1.80.1(stable/1.80)^t {big-endian clippy debug dist doc llvm-libunwind (+)lto miri nightly parallel-compiler profiler rust-analyzer rust-src rustfmt system-bootstrap system-llvm test verify-sig wasm ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 AMDGPU ARC ARM AVR BPF CSKY DirectX Hexagon Lanai LoongArch M68k MSP430 Mips NVPTX PowerPC RISCV SPIRV Sparc SystemZ VE WebAssembly X86 XCore Xtensa"} Homepage: https://www.rust-lang.org/ Description: Systems programming language from Mozilla [I] virtual/rust Available versions: ~1.71.0-r2(0/llvm-16) 1.71.1-r2(0/llvm-16) ~1.73.0-r1(0/llvm-17) 1.74.1-r1(0/llvm-17) 1.75.0-r1(0/llvm-17) ~1.76.0(0/llvm-17) 1.77.1(0/llvm-17) ~1.78.0(0/llvm-18) 1.79.0(0/llvm-18) ~1.80.1(0/llvm-18) {profiler rustfmt ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 1.79.0(0/llvm-18)(16:06:12 08/31/24)(-profiler -rustfmt ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32") Description: Virtual for Rust language compiler # eix -e openssl [I] dev-libs/openssl Available versions: [M]1.0.2u-r1^td [M]1.1.1w(0/1.1)^t 3.0.13-r2(0/3)^t ~3.0.14(0/3)^t ~3.1.6(0/3)^t ~3.2.2(0/3)^t ~3.3.1-r3(0/3)^t {+asm bindist fips gmp kerberos ktls +quic rfc3779 sctp sslv2 (+)sslv3 static-libs test tls-compression (+)tls-heartbeat vanilla verify-sig weak-ssl-ciphers ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="sse2"} Installed versions: 3.0.13-r2(0/3)^t(17:05:52 08/31/24)(asm -fips -ktls -rfc3779 -sctp -static-libs -test -tls-compression -vanilla -verify-sig -weak-ssl-ciphers ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="sse2") Homepage: https://openssl-library.org/ Description: Robust, full-featured Open Source Toolkit for the Transport Layer Security (TLS)
[I] dev-lang/rust-bin Available versions: (stable) ~1.71.0^s 1.71.1^s ~1.73.0^s 1.74.1^s 1.75.0^s ~1.76.0^s 1.77.1^s ~1.78.0^s 1.79.0^s ~1.80.1^s {big-endian clippy doc prefix profiler rust-analyzer rust-src rustfmt verify-sig ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="sse2"} Installed versions: 1.79.0(stable)^s(16:05:59 08/31/24)(-big-endian -clippy -doc -prefix -profiler -rust-analyzer -rust-src -rustfmt -verify-sig ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="sse2") Homepage: https://www.rust-lang.org/ Description: Systems programming language from Mozilla
Are you able to link with ssl on its own? e.g. $ gcc -o /tmp/test -x c - -lssl -lcrypto <<<"int main(void) { return 0; }" Unlikely to be an issue with maturin itself anyhow, toolchain or something else may be broken if normal "ld" that cargo is invoking can't find it. If you wanted to temporarily work around this, you could USE=-ssl on maturin though (it's not essential), but I imagine issue will come back on other packages.
@ionen: yes, it works as expected: $ gcc --version gcc (Gentoo Hardened 12.3.1_p20230526 p2) 12.3.1 20230526 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -o /tmp/test -x c - -lssl -lcrypto <<<"int main(void) { return 0; }" $ ldd /tmp/test /lib/ld-musl-x86_64.so.1 (0x7f5ae53bd000) libssl.so.3 => /usr/lib/libssl.so.3 (0x7f5ae5310000) libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x7f5ae4e00000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f5ae53bd000) this world update pulled in fresh gcc 13, but I guess it shouldn't matter? I'd prefer not to switch the compiler until profile migration is done...
Gave it a try in a musl chroot and seems I can reproduce, no idea why this is happening yet though or why this hasn't been reported earlier given maturin is somewhat commonly needed lately (maybe it broke recently).
fwiw other packages that use openssl-sys+OPENSSL_NO_VENDOR like yaskkserv2 also seem to fail the same way, not sure if it's something the openssl-sys crate is doing or if something else is going on, and if this used to work.
It's unrelated to ssl, but looks like it's further broken on musl. I'm getting a segmentation fault even if I get it to compile.
(In reply to Ionen Wolkens from comment #10) > It's unrelated to ssl, but looks like it's further broken on musl. I'm > getting a segmentation fault even if I get it to compile. Hm, no segfault when building without portage. Maybe related to something cargo.eclass does. Hopefully I'll be able to find some workarounds, not sure if it'll be today depending on how long it takes to experiment.
thank you Ionen! I tried compiling with USE="-ssl" as you suggested and it works, but I didn't resume update after
I figured why it doesn't find libssl/libcrypto, seems rust by default attempts to link statically only when using musl. So it's looking for the static libraries which aren't installed without USE=static-libs.
Looks like forcing -crt-static fixes everything including the segfaults I was getting. I'll go ahead and do that in the ebuild soon. Won't look at that myself, but should probably be considered for cargo.eclass though.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d99493b897e65d694e1cdcc717addde9802baed commit 0d99493b897e65d694e1cdcc717addde9802baed Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-09-01 12:09:32 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-09-01 13:00:07 +0000 dev-util/maturin: force shared build & fix tests for musl While it'd be nice to propagate the shared build, can skip the revbump (that'd be useless for glibc users given already default) given it either failed to build, or segfaulted while generating completion files. If it was successfully installed then it should be usable. patchelf could be skipped if we disable auditwheel (like distutils-r1 does), but not aware of an easy way to pass this for tests and it may confuse them either way -- so just add the cheap dependency. Closes: https://bugs.gentoo.org/938847 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-util/maturin/maturin-1.6.0.ebuild | 4 ++++ dev-util/maturin/maturin-1.7.0.ebuild | 4 ++++ dev-util/maturin/maturin-1.7.1.ebuild | 4 ++++ 3 files changed, 12 insertions(+)
