[OE-core] [PATCH] insane.bbclass: Fix RPATH warning in the face of funny path strings

[Andy Ross]

On 08/16/2012 01:39 AM, Phil Blundell wrote:
> If these RPATHs are causing host pollution then that sounds like there
> is another bug elsewhere.  They ought to be resolved relative to the
> sysroot during link edit.

Indeed, this is turning out to be a deeper issue than I wanted it to
be.  What seems to be is happening is this: an RPATH in the ELF header
is interpreted relative to sysroot normally.  But when linking, a
-rpath argument to the ld is interpreted relative to the *host*
filesystem even when there is a --sysroot argument.  See the quick
test script below.

As it happens, both of those are ultimately produced by libtool, and
it's only the second one that is fatal.  The RPATH itself is probably
still a warning condition, but it's not a build breaker.  But neither
is needed, they are happening in the case I'm looking at only because
libtool (I think) is confused by the "/../" syntax in the link path
into trying to add an RPATH where one isn't needed.

The specific case I'm looking at (with our internal tree, I'm working
on reproducing vs. poky right now) is with a pulseaudio build, where
an x86-64 build on an x86_64 host hits a RPATH in libgdk-x11-2.0 that
pulls in the host libXranr and fails due to version skew.  I was just
pointed at a discussion from last week on owl_video which looks all
but identical.

At least for the moment I'm going to try to track down the libtool
issue (maybe sanify the path before it sees if if possible) instead of
trying to fix a linker bug.

Andy

Reproducer for the underlying linker issue:

#!/bin/sh
set -ex

SYSROOT=/home/andy/oe/poky/build/tmp/sysroots/qemux86-64
CC=/home/andy/oe/poky/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-poky-linux/x86_64-poky-linux-gcc

# A library:
echo 'int foo(){return 0;}' > foo.c
$CC -shared -fPIC -o libfoo.so foo.c

# Another library that references the first via RPATH=`pwd`
echo 'int foo(); int bar(){return foo();}' > bar.c
$CC -shared -fPIC -o libbar.so bar.c -L. -lfoo -Wl,-rpath -Wl,`pwd`

# A program that uses the second library:
echo 'int bar(); int main(){return bar();}' > main.c

# Works (incorrectly!) because the "-rpath `pwd" argument here is
# *not* interpreted relative to sysroot, so the linker sees
# ./libfoo.so as a potential library.
$CC --sysroot=$SYSROOT -L$SYSROOT/usr/lib64 -Wl,-rpath -Wl,`pwd` -o main2 main.c libbar.so

echo THAT LINK SHOULD HAVE FAILED

# Fails (correctly) because nothing on the link line tells libbar.so
# how to find libfoo.so, nor does libfoo.so exist in the
# sysroot-relative RPATH.
$CC --sysroot=$SYSROOT -o main main.c libbar.so