Re: rust-1.81.0 & LLVM, LLD and cmake

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

> I've tried reading up the cmake docs on this.

Many thanks for the effort!

First off, I have now side-stepped the issue.  It turned out that
the problem came when trying to build the internal 'lld' shipped
as part of 'llvm' inside the rust distribution while trying to
use an external llvm of the same version as the embedded llvm
(18.x).  However, as near as I can tell, this build of 'lld' is
entirely optional, and has now been turned off under those
conditions in the pkgsrc-wip package for rust181 with

# Also turn off build of the internal LLD, as the external LLVM
# may be older (e.g. 17) than the internal LLD (now 18.x), ref.
# https://github.com/rust-lang/rust/issues/131291
CONFIGURE_ARGS+=        --set rust.lld=false

in options.mk.

> I found BUILD_RPATH_USE_ORIGIN.
> https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH_USE_ORIGIN.html#build-rpath-use-origin
>
> Can you turn that off for llvm?
>
> There's also CMAKE_SKIP_INSTALL_RPATH and CMAKE_SKIP_BUILD_RPATH if
> you want to completely disable use of rpath during install or build.
>
> Or try setting INSTALL_RPATH directly to the absolute paths.
> https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html#install-rpath
>
> The proper variable seems to be CMAKE_BUILD_RPATH_USE_ORIGIN which is
> used to initialize BUILD_RPATH_USE_ORIGIN. This is documented to
> default to false, but perhaps llvm sets it to true?
>
> https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH_USE_ORIGIN.html#prop_tgt:BUILD_RPATH_USE_ORIGIN

Hmm...  First off, if I recall correctly, the wrapper for cc /
gcc / ld all discard arguments containing $ORIGIN, so as long as
one uses the buildlink'ed tools, there's no way $ORIGIN can make
it into a shared library made with pkgsrc scaffolding / tools.
(Now, some of "my own" scaffolding for the rust package violates
this rule, especially when cross-compiling, due to the need to
additionally both add to and tweak the compiler arguments in
those cases, but then you don't use the native compiler anyway,
so what's wrong with that? :) .)

That said...  I'm hesitant to go trying to make intimate surgery
on the cmake setup for llvm in general or lld specifically.

There's also the consideration that rust when built natively is
built in stages (I think 3), and the individual stages are set up
to use the build results from the previous stage.

But...  Maybe that isn't a problem:

: {9} pwd
/usr/pkgsrc/wip/rust181/work/rustc-1.81.0-src/build/x86_64-unknown-netbsd/stage1/lib
: {10} 
: {11} readelf -a librustc_driver-b932f3affc40b04a.so | less
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstd-eb2f223165b952ea.so]
 0x0000000000000001 (NEEDED)             Shared library: [libLLVM.so.18.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.9]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.12]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.0]
 0x000000000000000f (RPATH)              Library rpath: [/usr/pkg/lib]
...
 0x000000000000001e (FLAGS)              ORIGIN BIND_NOW STATIC_TLS
 0x000000006ffffffb (FLAGS_1)            Flags: NOW ORIGIN
...

Maybe rust also(?) uses the LD_LIBRARY_PATH env var to direct it
where to find the shared libraries built by the previous stage?


So, in the absence of an exsting config hook to control this
(I've not checked, but am somewhat doubtful that it exists
already), one would have to figure out which of the cmake files
are generated and which ones are original, and where each
generated file fragment comes from.

That isn't exactly straight-forward, since the generated cmake
files don't say in comments where the original segments come
from, and the attitude seems to be "Here, let me toss you a
chaos, you figure out where the original individual pieces come
from when you pick it apart".

Have I said that I hate cmake yet? :)

Regards,

- Håvard