Yes, I am, although I've only taken cursory looks so far.
I've been seeing this on pkgsrc-bulk. If it were EL7 I wouldn't be
surprised, but as I dimly understand the RHEL-etc world this is
considered newish.
[...]
Package Breaks Maintainer
-------------------------------------------------------------------------
lang/rust 2922 pkgsrc-users%NetBSD.org@localhost
Doesn't repro on Fedora (although it did make my system unresponsive
on two consecutive tries!) or Debian so I'm going to set up a proper
Rock 9 environment to investigate - but at first glance the failure
does look a bit intimidating.
Sorry, I don't have access to any RHEL systems to reproduce or
debug.
It looks like linking of rustdoc-tool (possibly the first
executable being built -- just guessing...), fails with undefined
references to an external LLVM 15 (the bunch of symbols suffixed
with @LLVM15), and one symbol in zlib (compressBound@ZLIB_1.2.0).
Most of the LLVM symbols appear to be related to cross-building,
i.e. are related to presumed non-native targets, so depends on
the LLVM it tries to use actually being configured & built for
cross-compiling, i.e. supporting the rather long list of targets.
I would use 'nm' to list the symbols in the referenced libraries,
to see whether they are indeed missing, whether they have a
different suffix "or what". E.g. start with
nm -op /usr/pkg/lib/libLLVM-15.so | grep LLVMInitializeM68kTargetMC
A second suggestion could be to build rust using the embedded
LLVM in rust itself, i.e. with
PKG_OPTIONS.rust+= rust-internal-llvm
in /etc/mk.conf. Obviously, this will take longer...
I'm unsure of what the zlib issue is, though. Mismatch (version
skew?) between the header used and the library? Which header did
it use? Rust has its own zlib header (in
vendor/libz-sys/src/zlib/zlib.h), but possibly the link tries to
use the system zlib?
Some of the other options in options.mk may also need to be
looked at, e.g. rust-cargo-static, as that tends to change how
these vendored components are built and used.
Regards,
- Håvard