On Sunday 20 February 2011 19:26:23 Frans Meulenbroeks wrote: > 2011/2/20 Tom Rini <[email protected]>: > > On 02/20/2011 05:42 AM, Frans Meulenbroeks wrote: > >> 2011/2/19 Tom Rini<[email protected]>: > >>> On 02/19/2011 06:26 AM, Otavio Salvador wrote: > >>>> On Sat, Feb 19, 2011 at 11:52, Andreas Mueller<[email protected]> > >>>> > >>>> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
