[RFC] Enable --hash-style=both for all recent gcc4 targets

[RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

Hey guys,

I would start linking everything with -Wl,--hash-style=both as this is said to 
speed up the loading of shared libraries by about 50% (google is your 
friend). This is an option for binutils and was introduced with binutils 
2.17. Now there are two ways to achieve this:

Change TARGET_LDFLAGS in e.g. the distro config (as this knows if binutils has 
this option available) or to change the "specs" of gcc to enable this by 
default. There is a patch from debian for gcc4.3 but it is leaving 
arm/armeabi out. What do you guys prefer?

I'm pretty sure that we will want to use the GNU hash style at Openmoko and 
this is creating an interesting problem in regard to a full system upgrade 
(which is supposed to work). Again there are two ways. Use force and bump PE 
on each package but we should avoid this. I propose to rename PR to FILE_PR 
and change PR  to "${FILE_PR}${DISTRO_PR}" so everytime a distro is changing 
something that effects every package we can bump (e.g. Setting DISTRO_PR 
to .1 for Openmoko).

comments?
	z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 10:22, Holger Freyther wrote:
> Hey guys,
>
> I would start linking everything with -Wl,--hash-style=both as this is said to
> speed up the loading of shared libraries by about 50%

Also check the as-needed stuff from Poky:

ASNEEDED = "-Wl,--as-needed"
ASNEEDED_pn-console-tools = ""
ASNEEDED_pn-distcc = ""
ASNEEDED_pn-openobex = ""
ASNEEDED_pn-icu = ""
ASNEEDED_pn-xserver-kdrive-xomap = ""
ASNEEDED_pn-minimo = ""
ASNEEDED_pn-pciutils = ""
ASNEEDED_pn-puzzles = ""
ASNEEDED_pn-dialer = ""

TARGET_LDFLAGS += "${ASNEEDED}"

That should also reduce library load time *and* eliminate spurious deps.

> (google is your
> friend). This is an option for binutils and was introduced with binutils
> 2.17. Now there are two ways to achieve this:
>
> Change TARGET_LDFLAGS in e.g. the distro config (as this knows if binutils has
> this option available) or to change the "specs" of gcc to enable this by
> default. There is a patch from debian for gcc4.3 but it is leaving
> arm/armeabi out. What do you guys prefer?

It seems that the TARGET_LDFLAGS in distro would be the best option forward.

> I'm pretty sure that we will want to use the GNU hash style at Openmoko and
> this is creating an interesting problem in regard to a full system upgrade
> (which is supposed to work). Again there are two ways. Use force and bump PE
> on each package but we should avoid this.

PE is only there to fix versioning screwups (be it upstream or OE)

> I propose to rename PR to FILE_PR
> and change PR  to "${FILE_PR}${DISTRO_PR}" so everytime a distro is changing
> something that effects every package we can bump (e.g. Setting DISTRO_PR
> to .1 for Openmoko).

That sounds like a good idea, it would make changing compiler versions a 
lot safer.

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 10:51:33 Koen Kooi wrote:
> On 15-10-2008 10:22, Holger Freyther wrote:
> > Hey guys,
> >
> > I would start linking everything with -Wl,--hash-style=both as this is
> > said to speed up the loading of shared libraries by about 50%
>
> Also check the as-needed stuff from Poky:
>
> ASNEEDED = "-Wl,--as-needed"
> ASNEEDED_pn-console-tools = ""
> ASNEEDED_pn-distcc = ""
> ASNEEDED_pn-openobex = ""
> ASNEEDED_pn-icu = ""
> ASNEEDED_pn-xserver-kdrive-xomap = ""
> ASNEEDED_pn-minimo = ""
> ASNEEDED_pn-pciutils = ""
> ASNEEDED_pn-puzzles = ""
> ASNEEDED_pn-dialer = ""
>
> TARGET_LDFLAGS += "${ASNEEDED}"
>
> That should also reduce library load time *and* eliminate spurious deps.

Thanks. holger/hash-style has my take on that. It attempts to keep the 
enabling to the libc and distro and the blacklist can be shared among 
everyone.

comments? next stop would the hwcaps we have talked about.

z. 

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 23:17, Holger Freyther wrote:
> On Wednesday 15 October 2008 10:51:33 Koen Kooi wrote:
>> On 15-10-2008 10:22, Holger Freyther wrote:
>>> Hey guys,
>>>
>>> I would start linking everything with -Wl,--hash-style=both as this is
>>> said to speed up the loading of shared libraries by about 50%
>> Also check the as-needed stuff from Poky:
>>
>> ASNEEDED = "-Wl,--as-needed"
>> ASNEEDED_pn-console-tools = ""
>> ASNEEDED_pn-distcc = ""
>> ASNEEDED_pn-openobex = ""
>> ASNEEDED_pn-icu = ""
>> ASNEEDED_pn-xserver-kdrive-xomap = ""
>> ASNEEDED_pn-minimo = ""
>> ASNEEDED_pn-pciutils = ""
>> ASNEEDED_pn-puzzles = ""
>> ASNEEDED_pn-dialer = ""
>>
>> TARGET_LDFLAGS += "${ASNEEDED}"
>>
>> That should also reduce library load time *and* eliminate spurious deps.
>
> Thanks. holger/hash-style has my take on that. It attempts to keep the
> enabling to the libc and distro and the blacklist can be shared among
> everyone.
>
> comments?

Looks good, but I first would like to know how one can identify a recipe 
that breaks with as-needed. Does it fail to link, does it crash at 
runtime, etc?

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Marcin Juszkiewicz]

Thursday 16 of October 2008 09:05:01 Koen Kooi napisał(a):

> Looks good, but I first would like to know how one can identify a
> recipe that breaks with as-needed. Does it fail to link, does it

Fail to link.

-- 
JID: hrw@jabber.org

-Wl,as-needed, was; Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 16-10-2008 13:52, Marcin Juszkiewicz wrote:
> Thursday 16 of October 2008 09:05:01 Koen Kooi napisał(a):
>
>> Looks good, but I first would like to know how one can identify a
>> recipe that breaks with as-needed. Does it fail to link, does it
>
> Fail to link.

Great, it should be easy to spot and mark those.

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Phil Blundell]

On Wed, 2008-10-15 at 10:22 +0200, Holger Freyther wrote:
> I would start linking everything with -Wl,--hash-style=both as this is said to 
> speed up the loading of shared libraries by about 50% (google is your 
> friend). This is an option for binutils and was introduced with binutils 
> 2.17. Now there are two ways to achieve this:

If you are using a modern GNU runtime then I think it should be safe to
just select --hash-style=gnu.  This will give you the speed improvement
without the space penalty of two hashes.

> Change TARGET_LDFLAGS in e.g. the distro config (as this knows if binutils has 
> this option available) or to change the "specs" of gcc to enable this by 
> default. There is a patch from debian for gcc4.3 but it is leaving 
> arm/armeabi out. What do you guys prefer?

I guess you might as well put it in TARGET_LDFLAGS.  That's the less
intrusive change and there are already plenty of other flags there.

> Again there are two ways. Use force and bump PE 
> on each package but we should avoid this. I propose to rename PR to FILE_PR 
> and change PR  to "${FILE_PR}${DISTRO_PR}" so everytime a distro is changing 
> something that effects every package we can bump (e.g. Setting DISTRO_PR 
> to .1 for Openmoko).

I think this is an excellent plan.  As you say, PE changes are not
something to be done frivolously.

p.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 10:54:41 Phil Blundell wrote:
> On Wed, 2008-10-15 at 10:22 +0200, Holger Freyther wrote:
> > I would start linking everything with -Wl,--hash-style=both as this is
> > said to speed up the loading of shared libraries by about 50% (google is
> > your friend). This is an option for binutils and was introduced with
> > binutils 2.17. Now there are two ways to achieve this:
>
> If you are using a modern GNU runtime then I think it should be safe to
> just select --hash-style=gnu.  This will give you the speed improvement
> without the space penalty of two hashes.

Modern as in glibc 2.5? I think we could strip the .hash away. I'm waiting for 
my build to finish to get some numbers about the actual size difference. But 
I guess on (e)glibc 2.5 and above gnu would be good enough.


z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Phil Blundell]

On Wed, 2008-10-15 at 20:18 +0200, Holger Freyther wrote:
> Modern as in glibc 2.5? I think we could strip the .hash away. 

Right.  This was the glibc change that introduced gnu hash support:

2006-07-10  Ulrich Drepper  <drepper@redhat.com>

        * elf/dl-lookup.c (dl_new_hash): New functions.
        (_dl_lookup_symbol_x): Rename hash to old_hash and don't compute
        value here.  Compute new-style hash value.  Pass new hash value
        and reference to variable with the old value to do_lookup_x.
        (_dl_setup_hash): If DT_GNU_HASH is defined, use it and not
        old-style hash table.

I think it should even be fairly straightforward to backport that to
older glibcs if anybody wanted to do so.  As far as I know there is no
real reason for distros to require 2.4 or earlier though.

p.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 10:22:36 Holger Freyther wrote:

Okay, I have pushed holger/hash-style and would like to test and then merge 
this branch. Comments or better ideas welcome
	z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 11:04, Holger Freyther wrote:
> On Wednesday 15 October 2008 10:22:36 Holger Freyther wrote:
>
> Okay, I have pushed holger/hash-style and would like to test and then merge
> this branch. Comments or better ideas welcome
> 	z.

Your PR split commit has some unrelated changes in it:

+PKG_TAGS = ""
+DEPLOY_DIR_OPK = "${DEPLOY_DIR}/opk"
+SRCPV = "${@bb.fetch.get_srcrev(d)}"
+OPKGBUILDCMD = "opkg-build -O -o 0 -g 0"

It's also missing the actual bump for distro PR in the angstrom configs.

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 11:19:10 Koen Kooi wrote:
> On 15-10-2008 11:04, Holger Freyther wrote:
> > On Wednesday 15 October 2008 10:22:36 Holger Freyther wrote:
> >
> > Okay, I have pushed holger/hash-style and would like to test and then
> > merge this branch. Comments or better ideas welcome
> > 	z.
>
> Your PR split commit has some unrelated changes in it:
>
> +PKG_TAGS = ""
> +DEPLOY_DIR_OPK = "${DEPLOY_DIR}/opk"
> +SRCPV = "${@bb.fetch.get_srcrev(d)}"
> +OPKGBUILDCMD = "opkg-build -O -o 0 -g 0"

thanks. I will remove that.

z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 11:19:10 Koen Kooi wrote:
> On 15-10-2008 11:04, Holger Freyther wrote:
> > On Wednesday 15 October 2008 10:22:36 Holger Freyther wrote:
> >
> > Okay, I have pushed holger/hash-style and would like to test and then
> > merge this branch. Comments or better ideas welcome
> > 	z.
>
> Your PR split commit has some unrelated changes in it:
>
> +PKG_TAGS = ""
> +DEPLOY_DIR_OPK = "${DEPLOY_DIR}/opk"
> +SRCPV = "${@bb.fetch.get_srcrev(d)}"
> +OPKGBUILDCMD = "opkg-build -O -o 0 -g 0"
>
> It's also missing the actual bump for distro PR in the angstrom configs.

Okay,

do you think this version is ready to be merged?

z

PS: I forced an upgrade on the git branch

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 20:16, Holger Freyther wrote:
> On Wednesday 15 October 2008 11:19:10 Koen Kooi wrote:
>> On 15-10-2008 11:04, Holger Freyther wrote:
>>> On Wednesday 15 October 2008 10:22:36 Holger Freyther wrote:
>>>
>>> Okay, I have pushed holger/hash-style and would like to test and then
>>> merge this branch. Comments or better ideas welcome
>>> 	z.
>> Your PR split commit has some unrelated changes in it:
>>
>> +PKG_TAGS = ""
>> +DEPLOY_DIR_OPK = "${DEPLOY_DIR}/opk"
>> +SRCPV = "${@bb.fetch.get_srcrev(d)}"
>> +OPKGBUILDCMD = "opkg-build -O -o 0 -g 0"
>>
>> It's also missing the actual bump for distro PR in the angstrom configs.
>
> Okay,
>
> do you think this version is ready to be merged?

I'm undecided about putting the linker stuff in angstrom.inc vs. 
angstroom-<libc>.inc. Go for what you think is best :)

So, yes, it looks ready to get merged.

Signed-off-by: Koen Kooi <koen@openembedded.org>

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 20:24:07 Koen Kooi wrote:

> I'm undecided about putting the linker stuff in angstrom.inc vs.
> angstroom-<libc>.inc. Go for what you think is best :)

Google couldn't tell me if uclibc supports GNU style hashes, so I only change 
eglibc and glibc... happy rebuilding and I'm sorry when I broke things.

I decided to land now as PRs are changing all the time and keeping up with 
things is pretty hard...

z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 21:53, Holger Freyther wrote:
> On Wednesday 15 October 2008 20:24:07 Koen Kooi wrote:
>
>> I'm undecided about putting the linker stuff in angstrom.inc vs.
>> angstroom-<libc>.inc. Go for what you think is best :)
>
> Google couldn't tell me if uclibc supports GNU style hashes, so I only change
> eglibc and glibc... happy rebuilding and I'm sorry when I broke things.
>
> I decided to land now as PRs are changing all the time and keeping up with
> things is pretty hard...

You did change a S-O-B to an A-B, which AIUI is not how it should work. 
Time to update teh commit policy to include SOB and ABs?

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Holger Freyther]

On Wednesday 15 October 2008 21:58:40 Koen Kooi wrote:
> On 15-10-2008 21:53, Holger Freyther wrote:
> > On Wednesday 15 October 2008 20:24:07 Koen Kooi wrote:
> >> I'm undecided about putting the linker stuff in angstrom.inc vs.
> >> angstroom-<libc>.inc. Go for what you think is best :)
> >
> > Google couldn't tell me if uclibc supports GNU style hashes, so I only
> > change eglibc and glibc... happy rebuilding and I'm sorry when I broke
> > things.
> >
> > I decided to land now as PRs are changing all the time and keeping up
> > with things is pretty hard...
>
> You did change a S-O-B to an A-B, which AIUI is not how it should work.
> Time to update teh commit policy to include SOB and ABs?

Wow, I had to read that a couple of times. In Linux terms I would have to add  
a S-O-B to the commit. If it goes through your hands you add your S-O-B as 
well, if you just review and like the patch you ack?

yes, the policy needs update... and I will sleep now

z.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Henning Heinold]

Hi,

just checked for uclibc. It has the HASH support at least in the svn version
I checked, but it is disabled in our configs.

Bye Henning

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Tom Talpey]

At 06:43 PM 10/15/2008, Holger Freyther wrote:
>Wow, I had to read that a couple of times. In Linux terms I would have to add  
>a S-O-B to the commit. If it goes through your hands you add your S-O-B as 
>well, if you just review and like the patch you ack?

If you write code and add it to a patch, you generally sign it (S-O-B)
because you're asserting that your addition adheres to the relevant
license(s). If you merely approve of code and don't add any, then you
ack it (A-B).

There are lots of other amusing lines that are often added, but the
S-O-B one is the key, since it establishes the chain of responsibility.
Beginning with the submitter!

Do OE recipes have any particular licensing to govern any S-O-B terms?
If that's documented somewhere, I'd be interested to see it. There isn't
a license in the tree, that I've found.

Tom.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Phil Blundell]

On Thu, 2008-10-16 at 00:43 +0200, Holger Freyther wrote:
> Wow, I had to read that a couple of times. In Linux terms I would have to add  
> a S-O-B to the commit. If it goes through your hands you add your S-O-B as 
> well, if you just review and like the patch you ack?
> 
> yes, the policy needs update... and I will sleep now

I really don't think that we need to get into "Signed-off-by" and the
like.  That sort of process has some value for the kernel people because
they often have a lengthy chain of merge responsibility between the
originator of a given patch and the person who ultimately commits it
into the master tree.  Also, they are maintaining what is essentially a
single, coherent work for copyright purposes and hence they need to be
at least slightly careful about tracking ownership of IP rights.

Neither of these considerations really applies to the OE metadata
repository in its current form, and it's not clear what would be gained
by using or requiring this kind of signoff procedure.

p.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Leon Woestenberg]

Hello,

On Wed, Oct 15, 2008 at 10:22 AM, Holger Freyther <zecke@selfish.org> wrote:
> Hey guys,
>
> I would start linking everything with -Wl,--hash-style=both as this is said to
> speed up the loading of shared libraries by about 50% (google is your
>
If we care about dynamic link speed we should maybe revisit the rpath issue.

I remember seeing strace's where on each .so, 10 attempts were made
before the right location was attempted.

Actually, it is still on my to do:

http://bugs.openembedded.net/show_bug.cgi?id=2140

Regards,
-- 
Leon

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Phil Blundell]

On Wed, 2008-10-15 at 12:43 +0200, Leon Woestenberg wrote:
> If we care about dynamic link speed we should maybe revisit the rpath issue.
> 
> I remember seeing strace's where on each .so, 10 attempts were made
> before the right location was attempted.

Yes, certainly.  There's basically no excuse for having bogus RPATHs in
the output executables.

Isn't insane.bbclass meant to be checking for these nowadays?

p.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 12:43, Leon Woestenberg wrote:
> Hello,
>
> On Wed, Oct 15, 2008 at 10:22 AM, Holger Freyther<zecke@selfish.org>  wrote:
>> Hey guys,
>>
>> I would start linking everything with -Wl,--hash-style=both as this is said to
>> speed up the loading of shared libraries by about 50% (google is your
>>
> If we care about dynamic link speed we should maybe revisit the rpath issue.
>
> I remember seeing strace's where on each .so, 10 attempts were made
> before the right location was attempted.
>
> Actually, it is still on my to do:
>
> http://bugs.openembedded.net/show_bug.cgi?id=2140

Doesn't insane.bbclass log bad rpaths? Or are you talking about spurious 
rpaths that don't point to staging or workdir?
AIUI libtool 2.x should solve a lot of these.

regards,

Koen

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Richard Purdie]

On Wed, 2008-10-15 at 13:09 +0200, Koen Kooi wrote:
> On 15-10-2008 12:43, Leon Woestenberg wrote:
> > On Wed, Oct 15, 2008 at 10:22 AM, Holger Freyther<zecke@selfish.org>  wrote:
> >> Hey guys,
> >>
> >> I would start linking everything with -Wl,--hash-style=both as this is said to
> >> speed up the loading of shared libraries by about 50% (google is your
> >>
> > If we care about dynamic link speed we should maybe revisit the rpath issue.
> >
> > I remember seeing strace's where on each .so, 10 attempts were made
> > before the right location was attempted.
> >
> > Actually, it is still on my to do:
> >
> > http://bugs.openembedded.net/show_bug.cgi?id=2140
> 
> Doesn't insane.bbclass log bad rpaths? Or are you talking about spurious 
> rpaths that don't point to staging or workdir?
> AIUI libtool 2.x should solve a lot of these.

I think what Leon is referring to is where different hardware
capabilities are checked. In Poky I ended up disabling this as at least
on ARM there were an insane number of different combinations of paths
being checked for. The patch I added to disable it was:

http://svn.o-hand.com/view/poky/trunk/meta/packages/glibc/files/no-hwcaps.patch?rev=5087&view=markup

I've not seen bad RPATH values for quite a while now.

Cheers,

Richard

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Phil Blundell]

On Wed, 2008-10-15 at 12:31 +0100, Richard Purdie wrote:
> I think what Leon is referring to is where different hardware
> capabilities are checked. In Poky I ended up disabling this as at least
> on ARM there were an insane number of different combinations of paths
> being checked for. The patch I added to disable it was:

Right, the default set of hwcaps is probably a bit more inclusive than
most folks want.  I don't think this issue is specific to ARM though
it's possible that arm does have it worse than some other
architectures.  

As with so many things it is basically a DISTRO decision which hwcaps to
include in the list for ld.so.  I suppose the ideal thing would be to
have a variable LD_SO_CONSIDER_HWCAPS or some such, which could be set
by DISTRO.conf to specify which ones should be included.  For the
majority of single-target-platform DISTROs the answer is obviously going
to be none.

Another similar issue for embedded-type DISTROs to consider is
minimising the length of the linker search path by, for example,
eliminating /usr/lib in favour of putting everything in /lib.  (The same
goes for /usr/bin and /bin, of course.)  And of course, not putting
anything in /etc/ld.so.conf unless it's necessary: my openmoko install
seems to have /usr/X11R6/lib and /usr/local/lib listed in that file even
though neither directory actually exists in the filesystem, which will
be causing another 2*N useless path lookups for every library.

Plus of course, PACKAGE_SNAP_LIB_SYMLINKS will eliminate another source
of indirection and hence another dentry name lookup.

p.

Re: [RFC] Enable --hash-style=both for all recent gcc4 targets

[Koen Kooi]

On 15-10-2008 10:22, Holger Freyther wrote:
> Hey guys,
>
> I would start linking everything with -Wl,--hash-style=both as this is said to
> speed up the loading of shared libraries by about 50% (google is your
> friend). This is an option for binutils and was introduced with binutils
> 2.17. Now there are two ways to achieve this:
>
> Change TARGET_LDFLAGS in e.g. the distro config (as this knows if binutils has
> this option available) or to change the "specs" of gcc to enable this by
> default. There is a patch from debian for gcc4.3 but it is leaving
> arm/armeabi out. What do you guys prefer?

So, the first problem report:

gdb fails to build[1] with:

configure: loading cache .././config.cache
configure: error: `LDFLAGS' has changed since the previous run:
configure:   former value: 
-L/OE/angstrom-dev/staging/arm-oabi-angstrom-linux/usr/lib 
-Wl,-rpath-link,/OE/angstrom-dev/staging/arm-oabi-angstrom-linux/usr/lib 
-Wl,-O1 -Wl,--hash-style=gnu  -s
configure:   current value: 
-L/OE/angstrom-dev/staging/arm-oabi-angstrom-linux/usr/lib 
-Wl,-rpath-link,/OE/angstrom-dev/staging/arm-oabi-angstrom-linux/usr/lib 
-Wl,-O1 -Wl,--hash-style=gnu -s
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm .././config.cache' and 
start over
configure: error: /bin/sh 
'/OE/angstrom-dev/work/arm-oabi-angstrom-linux/gdb-6.8-r1.1/gdb-6.8/gdb/testsuite/configure' 
failed for testsuite

It seems that it's removing a stray space (' ') which trips up the 
build. Any ideas where this bug is being introduced?

regards,

Koen


[1] http://bugs.openembedded.net/show_bug.cgi?id=4733