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

[Richard Purdie]

On Thu, 2012-08-16 at 10:43 -0700, Andy Ross wrote:
> 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.

I suspect you need to look somewhere around:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/fix-rpath.patch

and normalise the rpaths being used by libtool. I think it has some kind
of path normalisation function somewhere...

Cheers,

Richard