[OE-core] [PATCH] relocatable.bbclass: do not erease already existing ORIGIN

Tom Rini tom.rini at gmail.com
Tue Mar 27 01:13:05 UTC 2012


On Mon, Mar 26, 2012 at 09:17:22AM -0700, Tom Rini wrote:
> On Sat, Mar 24, 2012 at 12:09:41PM +0100, Henning Heinold wrote:
> > Hi,
> > 
> > while building openjdk I discovered that relocatable.bbclass strips
> > all PATHS with ORIGIN, that is problematic, when binaries like an jdk
> > is installed not in the standard paths /lib or /usr/lib.
> > 
> > This patch let all exisiting ORIGIN stay in the binary. So
> > far I only saw problems with some perl-native libs, where chrpath fails
> > now, because the path is to long. But it seems they work anyway.
> > 
> > While letting the path stay in binary it occurs that whitespaces at the end
> > of the last path sneaked some how in. So I made re.sub line to clean this up.
> > 
> > Bye Henning
> > 
> > PS: I have to appologize, that I send it to oe-dev before.
> 
> I replied to the oe-dev thread, but I have some concerns I need to work
> out about this patch since perl is in a similar situation already.  And
> that some perl-native libs are complaining after this patch is also
> worrying given how much of a pain perl+$ORIGIN can be.

OK, can you describe the problem you see, exactly?  Using Angstrom, and
current sources, building icedtea6-native gives me:
trini at bill-the-cat:~/work/OE/angstrom/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/lib/jvm/icedtea6-native/bin$ readelf -d java | grep ORIGIN
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli]
 0x000000006ffffffb (FLAGS_1)            Flags: ORIGIN

So rpath isn't being clobbered today, but we aren't using all of our own
libs in these cases (zlib for example).  This is what I see both before
and after your patch is applied.

-- 
Tom




More information about the Openembedded-core mailing list