[oe] [PATCH] insane.bbclass: Make RPATH a non-fatal error

[Andreas Mueller]

On Sunday 20 February 2011 19:26:23 Frans Meulenbroeks wrote:
> 2011/2/20 Tom Rini <tom_rini at mentor.com>:
> > On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote:
> >> 2011/2/19 Tom Rini<tom_rini at mentor.com>:
> >>> On 02/19/2011 06:26 AM, Otavio Salvador wrote:
> >>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<schnitzeltony at gmx.de>
> >>>> 
> >>>>  wrote:
> >>>>> On Saturday 19 February 2011 10:45:38 Frans Meulenbroeks wrote:
> >>>>>> I am fine with the patch, but perhaps a better solution would be to
> >>>>>> introduce a var to decide whether it is a fatal or not.
> >>>>>> That way people distro's that use libtool 2.4 can decide to make it
> >>>>>> a fatal. (or individual users in their local.conf)
> >>>>>> 
> >>>>>> Frans
> >>>>> 
> >>>>> How comes that I sometimes feel handled as spammer ;-) ?
> >>>>> 
> >>>>> see http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-
> >>>>> February/029534.html
> >>>>> 
> >>>>> anyway - treating RPATH errors as fatal has lead to many QA fixes and
> >>>>> further
> >>>>> will follow...
> >>>>> 
> >>>>> my opinion now: keep RPATH errors fatal as developer's  whip :-)
> >>>> 
> >>>> I agree about keeping it configurable.
> >>>> 
> >>>> Besides I think that we ought to keep it fatal until quite near of
> >>>> release since we'll be "forced" to fix most of many of them.
> >>> 
> >>> I just want to state, again, that most of these just go away with
> >>> libtool 2.4.  Now, if people are looking for something to work on that
> >>> won't just go
> >>> away with an update to libtool 2.4:
> >>> - iscsi-target needs some love again for various kernel versions as
> >>> that looks to be killing calamari and neek for nas-server-image
> >> 
> >> Peeked at iscsi-target for calamari. Some inet fields have changed
> >> name in 2.6.32 or so, and apparently this is not handled fully.
> >> Instead of trying to fix it, I moved the calamari recipe to 2.6.34
> >> (which I'm already using for half a year or so, but apparently never
> >> pushed).
> > 
> > Thanks.
> > 
> >> I'll also see if I can update the neek version (probably also by
> >> moving the kernel version forward.
> >> Tomorrow I'll discuss this with Walter who afaik is the only other neek
> >> user.
> > 
> > Note that I also see:
> > - uclibc total failure, but I assume unsupported and I'll drop
> > - minimal fails everywhere else with:
> > ERROR: QA Issue with staging: libsupc++.la failed sanity test (workdir)
> > in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA Issue with staging: libstdc++.la failed sanity test
> > (workdir) in path
> > /var/hudson/workspace/sb_openembedded_autobuilder/BBPKGS/native-sdk-image
> > /DISTRO/minimal/MACHINE/neek/label/sb-u1004/tmp/sysroots/nios2-linux/usr/
> > lib ERROR: QA staging was broken by the package built above
> 
> Peeked some more itnto this.
> 
> If I peek in ./nios2-linux/usr/lib/libsupc++.la I see:
> 
> # libsupc++.la - a libtool library file
> # Generated by ltmain.sh - GNU libtool 1.4a-GCC3.0 (1.641.2.256
> 2001/05/28 20:09:07 with GCC-local changes)
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
> 
> # The name that we can dlopen(3).
> dlname=''
> 
> # Names of this library.
> library_names=''
> 
> # The name of the static archive.
> old_library='libsupc++.a'
> 
> # Libraries that this one depends upon.
> dependency_libs='
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.1
> .2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.
> 1.2/build.i686-linux.nios2-linux/nios2-linux/libstdc++-v3/src/.libs -lm
> -L/home/frans/oe/tmp_minimal/work/nios2-linux/gcc-cross-4.1.2-r27.2/gcc-4.
> 1.2/build.i686-linux.nios2-linux/./gcc
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/bin
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-l
> inux/4.1.2
> -L/home/frans/oe/tmp_minimal/sysroots/i686-linux/usr/nios2/lib/gcc/nios2-l
> inux/4.1.2/../../../../nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/lib
> -L/home/frans/oe/tmp_minimal/sysroots/nios2-linux/usr/lib -lgcc_s -lc
> -lgcc_s
> 
> ...
> 
> For other platforms I see
> # libsupc++.la - a libtool library file
> # Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
> #
> # Please DO NOT delete this file!
> # It is necessary for linking the library.
> 
> # The name that we can dlopen(3).
> dlname=''
> 
> # Names of this library.
> library_names=''
> 
> # The name of the static archive.
> old_library='libsupc++.a'
> 
> # Linker flags that can not go in dependency_libs.
> inherited_linker_flags=''
> 
> # Libraries that this one depends upon.
> dependency_libs=''
> ...
> 
> Note the different versions of libtool and the different dependency libs
> I guess the libsupc++ comes from gcc and nios2 has a very old gcc
> (4.1.2), but there is no newer version (nios2 support is not
> mainlined).
> Anyone a suggestion?
> 
> Frans.
In my case the QA RPATH error was caused by the value found in 

libdir=..

But here situation seems a bit different. How about manually setting to correct 

libdir=/usr/lib

and continue build?

Andreas