Re: [OE-core] [PATCH] rust: Use llvm-config from native llvm-rust on rust target builds

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2024-01-15 at 08:56 -0800, Khem Raj wrote:
> Hi
> 
> On Mon, Jan 15, 2024 at 5:19 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Sat, 2024-01-13 at 21:58 -0800, Khem Raj wrote:
> > > target rust recipe builds ( cross compile ) calls llvm-config
> > > from
> > > target sysroot which works ok as long as C++ runtime it needs is
> > > available on build host e.g. libstdc++ etc. which is commonly the
> > > case, however when using clang and llvm runtime this falters
> > > since
> > > it should be using libc++ from native sysroot and if this does
> > > not
> > > exist on build machine this fails to find libc++ shared object
> > > and
> > > llvm-config fails to run. This ensures that llvm-config version
> > > in
> > > use is correctly relocated and can use shared libraries from
> > > native
> > > sysroot correctly. Adding ORIGIN to sysroot will look for the .so
> > > in
> > > same dir as the binary and there is the libc++.so.1 copied in
> > > place
> > > 
> > > Fixes rust build with clang compiler.
> > > 
> > > > /mnt/b/yoe/master/build/tmp/work/riscv64-yoe-
> > > > linux/rust/1.74.1/recipe-sysroot/usr/lib/llvm-rust/bin/llvm-
> > > > config: error while loading shared libraries: libc++.so.1:
> > > > cannot open shared object file: No such file or director
> > > y
> > > > thread 'main' panicked at llvm.rs:551:19:
> > > > command did not execute successfully:
> > > > "/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-
> > > > linux/rust/1.74.1/recipe-sysroot/usr/lib/llvm-rust/bin/llvm-
> > > > config" "--version"
> > > > expected success, got: exit status: 127
> > > 
> > > Signed-off-by: Khem Raj <raj.khem@gmail.com>
> > > ---
> > >   meta/recipes-devtools/rust/rust_1.74.1.bb | 8 ++++++--
> > >   1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meta/recipes-devtools/rust/rust_1.74.1.bb
> > > b/meta/recipes-devtools/rust/rust_1.74.1.bb
> > > index 30543ada7db..2dffe009827 100644
> > > --- a/meta/recipes-devtools/rust/rust_1.74.1.bb
> > > +++ b/meta/recipes-devtools/rust/rust_1.74.1.bb
> > > @@ -198,9 +198,13 @@ rust_runx () {
> > >       # Copy the natively built llvm-config into the target so we
> > > can run it. Horrible,
> > >       # but works!
> > >       if [ ${RUST_ALTERNATE_EXE_PATH_NATIVE} !=
> > > ${RUST_ALTERNATE_EXE_PATH} -a ! -f ${RUST_ALTERNATE_EXE_PATH} ];
> > > then
> > > -        mkdir -p `dirname ${RUST_ALTERNATE_EXE_PATH}`
> > > +        tgtdir=`dirname ${RUST_ALTERNATE_EXE_PATH}`
> > > +        mkdir -p ${tgtdir}
> > >           cp ${RUST_ALTERNATE_EXE_PATH_NATIVE}
> > > ${RUST_ALTERNATE_EXE_PATH}
> > > -        chrpath -d ${RUST_ALTERNATE_EXE_PATH}
> > > +        if [ -e ${STAGING_LIBDIR_NATIVE}/libc++.so.1 ]; then
> > > +            cp ${STAGING_LIBDIR_NATIVE}/libc++.so.1 ${tgtdir}/
> > > +        fi
> > > +        chrpath -r \$ORIGIN ${RUST_ALTERNATE_EXE_PATH}
> > >       fi
> > >   
> > >       oe_cargo_fix_env
> > 
> > Copying a native library into the target sysroot goes beyond what
> > I'm
> > comfortable with even for this horrible hack with llvm-config.
> > 
> 
> 
> It’s just supporting the original hack to work properly I don’t think
> it’s any worse that the original hack 

Putting a non-target library into the target sysroot could cause all
kinds of problems if the target and native are similar enough the
libraries can be seen and confused by the linker. I do see that as a
big and potentially very dangerous difference.

> > 
> > 
> > Since it seems to be finding it by RPATH, can you not just add an
> > RPATH
> > to the native sysroot in the binary?
> > 
> 
> 
> It does not work and I don’t know why but seems rpath in llvm-config
> affects what paths it spits out 

I am reluctant to take this without a better understanding of what is
going on here. We may need to fix the lvm-config issues properly.

Cheers,

Richard