$ORIGIN in RPATH suppression

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

as some of you may have noticed, I've muttered that the rust
compiler in wip/rust183/ can no longer be cross-built the same
way rust 1.82 could.  This has at least been noted / reported
upstream with the second part of

  https://github.com/rust-lang/rust/issues/133629

The specific issue is

/usr/pkgsrc/wip/rust183/work/rustc-1.83.0-src/build/x86_64-unknown-netbsd/stage1/bin/rustc: Shared object "librustc_driver-299f82a8112084d1.so" not found

When doing a cross-build using the pkgsrc scaffolding in
wip/rust*, rust builds "itself" in several stages, and uses the
intermediate build results to run the next stage.  When building
rust 1.82 on NetBSD/amd64 for NetBSD/evbearmv7-hf, the stages
shown in the first attachment are built.  However, when building
1.83, the build bombs out on the first invocation of the "stage1"
rustc compiler with the above error; it comes as far as shown in
the second attachment below (these only show the lines in the
build log matching "^Build").

I have concluded that the reason this fails is that the rust
compiler now depends on RPATH $ORIGIN processing, and that
pkgsrc's cwrappers are actively removing "non-absolute paths" in
rpath arguments, among them $ORIGIN arguments.  The
work/.work.log file contains the gcc invocation with

 [...] -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib'

but if I substitute a shell script in place of the gcc symlink
cwrappers use, and which logs its arguments and executes
/usr/bin/gcc with them, the rpath argument with $ORIGIN is gone.

I have made feeble and so far unsuccessful attempts at disabling
the "discard non-absolute arguments to rpath" from cwrappers.
However, I am quite certain that if the above use of $ORIGIN is
permitted, the rust cross-compile would succeed, it certainly
would come a lot further.

I have also tried to decipher the diffs between rust 1.82 and
rust 1.83 to find out "what changed to cause this failure with
1.83", e.g. "did the build infrastructure set LD_LIBRARY_PATH
earlier?!?", but have come up empty.  Help solicited.

The rust build infrastructure is quit"something else", the
configure phase and the top-level build is written in python,
while lots of the other build steps are written in rust, and run
by code compiled with the "previous" rust compiler, and some of
it relies on the rust ecosystem build tool 'cargo'.

So why, exactly, do we have a de-facto hostility towards the use
of $ORIGIN in RPATH?  To me it seems like a perfectly reasonable
feature to have the possibility to move the installed tree for a
package around and having it continue working without having to
use patchelf to set the RPATH to point statically to the new
install location for any shared libraries which are needed.

I have heard mutterings that $ORIGIN is not guaranteed to work in
100.0000% of cases, citing extreme corner cases where there is
memory pressure on the vnode cache(?) or similar extreme and
similarly unlikely conditions, but the $ORIGIN feature *is*
documented in our ld.elf_so(1) man page with no reservations, so
I think this argument is extremely weak, and an expression of an
attitude that "the world must revolve around and adapt to MY
decisions", which is IMHO counter-productive.

Getting the rust ecosystem to no longer rely on $ORIGIN for our
OS, especially when it is a documented feature without any
reservations of our ld.elf_so seems to me like tilting at
windmills.


So...  What is the *actual* *defensible* reason we continue to
disallow the use of $ORIGIN in RPATH in pkgsrc?  And if no such
defensible reason can be put forward, can we please stop
suppressing this?  Pretty, please?

Alternatively, can I get the nay-sayers to help with getting
wip/rust183 cross-building again?  I'm not keeping my breath
waiting, my somewhat negatively anticipation is that the
intersection between "nay-sayers" and "helpers" will be the empty
set. :(


For the time being, rust 1.83 can be built natively on the
platforms which support native self-hosting (it takes a lot
longer, though), but that discards our 32-bit arm ports by the
wayside, as well as the no-longer-functional 32-bit mips port.


Somewhat annoyed, but nevertheless Happy New Year,

- Håvard

Building bootstrap
Building stage0 library artifacts (x86_64-unknown-netbsd)
Building LLVM for x86_64-unknown-netbsd
Building compiler artifacts (stage0 -> stage1, x86_64-unknown-netbsd)
Building LLD for x86_64-unknown-netbsd
Building stage0 tool lld-wrapper (x86_64-unknown-netbsd)
Building stage0 tool wasm-component-ld (x86_64-unknown-netbsd)
Building tool llvm-bitcode-linker (stage0 -> stage1, x86_64-unknown-netbsd)
Building stage1 library artifacts (x86_64-unknown-netbsd -> armv7-unknown-netbsd-eabihf)
Building stage1 library artifacts (x86_64-unknown-netbsd)
Building LLVM for armv7-unknown-netbsd-eabihf
Building compiler artifacts (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building LLD for armv7-unknown-netbsd-eabihf
Building stage1 tool lld-wrapper (x86_64-unknown-netbsd -> armv7-unknown-netbsd-eabihf)
Building stage1 tool wasm-component-ld (x86_64-unknown-netbsd -> armv7-unknown-netbsd-eabihf)
Building tool llvm-bitcode-linker (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool rustdoc (stage1 -> stage2, armv7-unknown-netbsd-eabihf)
Building tool rust-analyzer-proc-macro-srv (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building stage0 tool rust-installer (x86_64-unknown-netbsd)
Building tool cargo (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool rls (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool rust-analyzer (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool rustfmt (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool cargo-fmt (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool clippy-driver (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Building tool cargo-clippy (stage1:x86_64-unknown-netbsd -> stage2:armv7-unknown-netbsd-eabihf)
Build completed successfully in 1:33:44

Building bootstrap
Building LLVM for armv7-unknown-netbsd-eabihf
Building LLVM for x86_64-unknown-netbsd
Building stage0 library artifacts (x86_64-unknown-netbsd)
Building compiler artifacts (stage0 -> stage1, x86_64-unknown-netbsd)
Building LLD for x86_64-unknown-netbsd
Building stage0 tool lld-wrapper (x86_64-unknown-netbsd)
Building stage0 tool wasm-component-ld (x86_64-unknown-netbsd)
Building tool llvm-bitcode-linker (stage0 -> stage1, x86_64-unknown-netbsd)
Building stage1 library artifacts (x86_64-unknown-netbsd -> armv7-unknown-netbsd-eabihf)
Building stage1 library artifacts (x86_64-unknown-netbsd)