Re: Rust broken again! (but differently this time)

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

> Tobias Nygren <tnn%NetBSD.org@localhost> writes:
>
>> Rust is now sadly broken on aarch64 too (and probably all arches except
>> amd64?). The bootstrap binaries need libLLVM-8.so which came implicitly
>> from lang/llvm, which was just updated to version 9. So we have nothing
>> that provides libLLVM-8.so. I guess the bootstrap files have to be
>> updated. It's better if we can make it use the built-in llvm
>> so it doesn't rely on existence of pkgsrc libraries.
>
> It seems we either need a plan that lets rust updates happen without
> breakage, or perhaps to have versinoed rust packages so that adding the
> new doesn't break the old, and we can flip them to newer per
> os/version/cpu as it's known to work.  But I am unclear on the details
> and if this actually makes sense.    It is merely clear that the current
> situation leads to frequent inability to build :-)

A progress report on this issue:


This (references to libLLVM-8.so) was caused by me not building the
bootstrap kits with

PKG_OPTIONS.rust= rust-llvm

The current status of building rust 1.38.0 with this option added
is as follows:

NetBSD/aarch64 9.0_BETA 1.38.0 bootstrap built & uploaded
NetBSD/i386 8.0 1.38.0 bootstrap	 built & uploaded
NetBSD/amd64 uses the rust-community-built bootstrap (so doesn't
have this problem)

The rust package has not yet been updated to refer to these
bootstraps; I discovered that if you try to use the 1.38.0 bootstrap
to build rust 1.38.0, it will fail, ref.

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

The patch to workaround this is simple enough, though ("don't make
warnings fatal"), and I'll add this patch and bump the bootstrap for
the above versions shortly.


NetBSD/sparc64 9.0_BETA 1.38.0 build is still ongoing -- our nice
Sun Ultra Enterprise 450 is unstable in MP mode, so we limp along on
one processor...


All these builds have to be done natively, since rust lost its
ability to cross-build a few versions back, ref.

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

BTW, there's a reference in that issue to

  https://github.com/alexcrichton/rustc-auto-publish/pull/11

claiming that it fixes (or at least tries to fix?) the original
issue, but I've not been able to figure out whether this is part of
rust (e.g. which src/main.rs is being patched?) and/or whether this
is part of 1.38.0 (it probably isn't).  We'll see with 1.39.0 when
that is released.


However, for NetBSD/macppc (powerpc) 8.0, I appear to have hit a
snag -- the build with the internal llvm (which is version 9.0.0)
does not succeed -- one of the tools built & used during the
build crashes with a SEGV, ref.

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

while using the pkgsrc 8.0.0 version succeeds, but then of course
depends on the pkgsrc llvm 8 shared libraries.

For NetBSD/macppc 8.0, I've tar'ed up the llvm (and clang) version 8
shared libraries, and will re-try the build using the pkgsrc version
9.0.0nb1 llvm, with my saved llvm 8 shared libs, which the bootstrap
will in all probability need.  We'll see how that goes but I'm not
hopeful -- I have a nagging suspicion this is an llvm regression
from version 8.0.0 to 9.0.0 for the powerpc target.  Hints and/or
help for chasing that down welcome.


I've also looked into whether I could get NetBSD/macppc 9.0_BETA to
build rust 1.38.0 if I add the recently added compat80 package, but
that's also a "no go" at the moment, despite having pkgsrc llvm
8.0.0 installed.  The build fails with

error: couldn't load codegen backend "/usr/pkgsrc/lang/rust/work/rust-bootstrap/lib/rustlib/powerpc-unknown-netbsd/codegen-backends/librustc_codegen_llvm-llvm.so": "/usr/pkgsrc/lang/rust/work/rust-bootstrap/lib/rustlib/powerpc-unknown-netbsd/codegen-backends/librustc_codegen_llvm-llvm.so: Undefined PLT symbol \"_ZN4llvm6Triple9normalizeENS_9StringRefE\" (symnum = 87)"

That is "llvm::Triple::normalize(llvm::StringRef)" says c++filt.
Grep'ing part of that symbol in libLLVM.so gives me:

% nm -Cop /usr/pkg/lib/libLLVM.so | grep llvm::Triple::normalize
/usr/pkg/lib/libLLVM.so:0052c89c T llvm::Triple::normalize[abi:cxx11](llvm::StringRef)
%

I was told that the '[abi:cxx11]' thing was something from early
NetBSD 9.0_BETA, and that the change which was responsible for its
insertion had been reverted, but updating to a recent 9.0_BETA and
re-building llvm did exactly nothing to fix this, so color me
confused on this one.  Help for figuring that out also much
appreciated.


Best regards,

- Håvard