Re: OK to inject BUILDLINK_PASSTHRU_RPATHDIRS into lang/rust?

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

Following up on this tangent:

> How are the efforts going for upstreaming those 58 patches pkgsrc
> carries for lang/rust? Is the rust project hostile to attempts to flex
> builds from source into using external libraries, integrate in
> distributions? It do see a number of insertions of @PREFIX@/lib into
> library search or rpath flags in rust.

Well.  The patches we carry around in the rust package come in a
few different categories:

 * Patches which are specific to pkgsrc.  E.g. rust by default
   builds with $ORIGIN/../lib in RPAPTH, but pkgsrc's compiler
   wrappers implements the pkgsrc policy that non-absolute paths
   in RPATH are forbidden, so this argument is simply dropped by
   the compiler wrappers.  This is what gives rise to the need to
   insert @PREFIX@/lib into RPATH, and to run patchelf in the
   rust-bin package (since the user's @PREFIX@ may be different
   from the default /usr/pkg).

   Patches of this sort are probably going to be rejected by the
   rust project, so I've not even tried.

   In this category we also find patches to add -latomic on
   powerpc, which is needed by the newer embedded LLVM.

 * Patches which are for adaptations for specific targets.  I try
   to submit these upstream.

   Some targets are ... "more experimental", such as 64-bit mips
   little-endian or arm64 big-endian, which requires more testing
   before submission.

   Other tweaks are "do not attempt to use incremental mode on
   NetBSD/sparc64", it's possible that should be upstreamed, the
   patch was taken from Debian if the comments are to be beleived.

   Patches which are workarounds for earlier versions of NetBSD,
   such as bugs related to thread-local storage will probably
   also not be accepted upstream.

 * Patches which are for specific bugs upstream, such as the "use
   __getmntinfo13 for getmntinfo()".  Generally I try to submit
   these upstream.  However, since the patches in rust for this
   issue are for specific versions of the "libc" crate, these
   patches will have to live in the package until that specific
   version is no longer used by upstream.  The fix will
   eventually appear in a newer upstream version, but then the
   upstream rust has to start using that version, and that's
   outside of our control.

 * And ... some of the patches are a mix of some of the above,
   such as the patch to src/bootstrap/bootstrap.py, and it's a
   bit of a pain to separate out the "upstreamable" portion, and
   doing so will anyway not cause the patch to no longer be
   needed.

 * Some patches (those related to SunOS / Illumos or Darwin), I
   personally can't test or tell whether they're upstream-
   adoptable candidates or not.

 * Some patches actually come as a result of submitting build bug
   reports upstream, e.g. the clippy_utils patch to allow build
   on 32-bit mips.  Will be dropped when upstream distributes
   fix.

 * A bunch of fixes for aarch64_be support.  In the current
   version NEON isn't supported in big-endian mode on aarch64, so
   there's a bunch of "fixing assumptions" that "aarch64 means
   you can do NEON".  There's probably a kernel of truth in "only
   weirdos run aarch64 in big-endian mode".

   Reportedly the NEON intrinsics will be fixed upstream, at
   which point lots of these patches need to be un-done to take
   advantage of NEON on big-endian aarch64.  Some of those
   patches have in fact been submitted and accepted by upstream
   crate maintainers (not main rust, IIRC), so that also needs to
   be un-done.

   The fixing of the NEON intrinsics didn't happen with rust
   1.86.0, but I am guessing there is work ahead for doing pkgsrc
   for 1.87.0 related to this.

 * Some patches are for arch+OS-specific issues, e.g.
   NetBSD/riscv64.  These have not yet been submitted upstream.
   The modus operandi is "fix it first in pkgsrc", and upstream
   if it works and time and energy permits.  So far the two
   latter hasn't fallen into place.

   Sometimes it's also a difference between "what can I commit to
   pkgsrc-wip and what will be accepted upstream", i.e. I may
   have stumbled on a problem, but the fix is a kludge.
    
 * Some upstreams are Special.  E.g. the vendor/openssl-src crate
   is IIRC maintained by the OpenSSL project, which requires
   legal paperwork for accepting submissions.  That created
   enough of a barrier that I didn't follow through.

Regards,

- Håvard