[master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

From: Christopher Larson <chris_larson@mentor.com>

We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
this in the toolchain, while convenient, actually hides bugs, as a failure to
obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
poison the sysroot -- rather than relying on the default, notice right away if
somoeone isn't obeying the needed flags.

This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
which is what's often seen with external toolchains. This brings us all on the
same page, and makes sure a failure to obey LDFLAGS is seen early.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
---
 meta/recipes-devtools/gcc/gcc-4.9.inc | 1 -
 meta/recipes-devtools/gcc/gcc-5.3.inc | 1 -
 2 files changed, 2 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 7e03f31..c187918 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
@@ -111,7 +111,6 @@ EXTRA_OECONF_BASE = "\
     --disable-bootstrap \
     --disable-libmudflap \
     --with-system-zlib \
-    --with-linker-hash-style=${LINKER_HASH_STYLE} \
     --enable-linker-build-id \
     --with-ppl=no \
     --with-cloog=no \
diff --git a/meta/recipes-devtools/gcc/gcc-5.3.inc b/meta/recipes-devtools/gcc/gcc-5.3.inc
index 9808be1..f2eda18 100644
--- a/meta/recipes-devtools/gcc/gcc-5.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-5.3.inc
@@ -112,7 +112,6 @@ EXTRA_OECONF_BASE = "\
     --disable-bootstrap \
     --disable-libmudflap \
     --with-system-zlib \
-    --with-linker-hash-style=${LINKER_HASH_STYLE} \
     --enable-linker-build-id \
     --with-ppl=no \
     --with-cloog=no \
-- 
2.8.0

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]


> On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com> wrote:
> 
> From: Christopher Larson <chris_larson@mentor.com>
> 
> We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
> this in the toolchain, while convenient, actually hides bugs, as a failure to
> obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> poison the sysroot -- rather than relying on the default, notice right away if
> somoeone isn't obeying the needed flags.
> 
> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> which is what's often seen with external toolchains. This brings us all on the
> same page, and makes sure a failure to obey LDFLAGS is seen early.
> 


Default or gnu linkers is to use sysv for legacy reasons and by passing this option
to configuring the toolchain we want to make sure that components are using sane defaults
even if they have not configured these options.

if you do not pass the right linker flags from compiler driver and also ignore
the LDFLAGS then you now have a safe pass for the app to build without GNU hash
while I understand it will spread the external toolchain’s pains into internal toolchain
I fail to understand the benefit of doing this otherwise.

> Signed-off-by: Christopher Larson <chris_larson@mentor.com>
> ---
> meta/recipes-devtools/gcc/gcc-4.9.inc | 1 -
> meta/recipes-devtools/gcc/gcc-5.3.inc | 1 -
> 2 files changed, 2 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc b/meta/recipes-devtools/gcc/gcc-4.9.inc
> index 7e03f31..c187918 100644
> --- a/meta/recipes-devtools/gcc/gcc-4.9.inc
> +++ b/meta/recipes-devtools/gcc/gcc-4.9.inc
> @@ -111,7 +111,6 @@ EXTRA_OECONF_BASE = "\
>     --disable-bootstrap \
>     --disable-libmudflap \
>     --with-system-zlib \
> -    --with-linker-hash-style=${LINKER_HASH_STYLE} \
>     --enable-linker-build-id \
>     --with-ppl=no \
>     --with-cloog=no \
> diff --git a/meta/recipes-devtools/gcc/gcc-5.3.inc b/meta/recipes-devtools/gcc/gcc-5.3.inc
> index 9808be1..f2eda18 100644
> --- a/meta/recipes-devtools/gcc/gcc-5.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-5.3.inc
> @@ -112,7 +112,6 @@ EXTRA_OECONF_BASE = "\
>     --disable-bootstrap \
>     --disable-libmudflap \
>     --with-system-zlib \
> -    --with-linker-hash-style=${LINKER_HASH_STYLE} \
>     --enable-linker-build-id \
>     --with-ppl=no \
>     --with-cloog=no \
> --
> 2.8.0
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com>
> wrote:
> >
> > From: Christopher Larson <chris_larson@mentor.com>
> >
> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
> default to
> > this in the toolchain, while convenient, actually hides bugs, as a
> failure to
> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how
> we
> > poison the sysroot -- rather than relying on the default, notice right
> away if
> > somoeone isn't obeying the needed flags.
> >
> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
> failure,
> > which is what's often seen with external toolchains. This brings us all
> on the
> > same page, and makes sure a failure to obey LDFLAGS is seen early.
> >
>
>
> Default or gnu linkers is to use sysv for legacy reasons and by passing
> this option
> to configuring the toolchain we want to make sure that components are
> using sane defaults
> even if they have not configured these options.
>

But that's not what we want. We want to know when we're not passing
arguments we need to be passing. For example, the sysroot is poisoned
today, so we *know* when the user is trying to run it without --sysroot=.

if you do not pass the right linker flags from compiler driver and also
> ignore
> the LDFLAGS then you now have a safe pass for the app to build without GNU
> hash
> while I understand it will spread the external toolchain’s pains into
> internal toolchain
> I fail to understand the benefit of doing this otherwise.


Silently ignoring the fact that recipes ignore LDFLAGS is not good default
behavior, and this is precisely what oe-core is doing today. If you know of
a better way to detect that in another QA check, I'm certainly open to
hearing it.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2781 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2600 bytes --]


> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com> wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> 
> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com <mailto:kergoth@gmail.com>> wrote:
> >
> > From: Christopher Larson <chris_larson@mentor.com <mailto:chris_larson@mentor.com>>
> >
> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
> > this in the toolchain, while convenient, actually hides bugs, as a failure to
> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> > poison the sysroot -- rather than relying on the default, notice right away if
> > somoeone isn't obeying the needed flags.
> >
> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> > which is what's often seen with external toolchains. This brings us all on the
> > same page, and makes sure a failure to obey LDFLAGS is seen early.
> >
> 
> 
> Default or gnu linkers is to use sysv for legacy reasons and by passing this option
> to configuring the toolchain we want to make sure that components are using sane defaults
> even if they have not configured these options.
> 
> But that's not what we want. We want to know when we're not passing arguments we need to be passing. For example, the sysroot is poisoned today, so we *know* when the user is trying to run it without --sysroot=.

application makefiles can ignore environment e.g. CC, CXX, LD etc and get into same situations.
as an application writer I may not be interested in using cross compilation specific nuances.  We may not
be able to solve it completely

> 
> if you do not pass the right linker flags from compiler driver and also ignore
> the LDFLAGS then you now have a safe pass for the app to build without GNU hash
> while I understand it will spread the external toolchain’s pains into internal toolchain
> I fail to understand the benefit of doing this otherwise.
> 
> Silently ignoring the fact that recipes ignore LDFLAGS is not good default behavior, and this is precisely what oe-core is doing today. If you know of a better way to detect that in another QA check, I'm certainly open to hearing it.

linker would emit .hash for sysv and .gnu.hash section for gnu hash in final ELF, may be adding a QA check for that would be enough ?

> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics


[-- Attachment #1.2: Type: text/html, Size: 4430 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

On Mon, May 2, 2016 at 9:37 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com> wrote:
>
>
>
> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com>
>> wrote:
>> >
>> > From: Christopher Larson <chris_larson@mentor.com>
>> >
>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
>> default to
>> > this in the toolchain, while convenient, actually hides bugs, as a
>> failure to
>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to
>> how we
>> > poison the sysroot -- rather than relying on the default, notice right
>> away if
>> > somoeone isn't obeying the needed flags.
>> >
>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>> failure,
>> > which is what's often seen with external toolchains. This brings us all
>> on the
>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>> >
>>
>>
>> Default or gnu linkers is to use sysv for legacy reasons and by passing
>> this option
>> to configuring the toolchain we want to make sure that components are
>> using sane defaults
>> even if they have not configured these options.
>>
>
> But that's not what we want. We want to know when we're not passing
> arguments we need to be passing. For example, the sysroot is poisoned
> today, so we *know* when the user is trying to run it without --sysroot=.
>
>
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get
> into same situations.
> as an application writer I may not be interested in using cross
> compilation specific nuances.  We may not
> be able to solve it completely
>


I'm not sure what you mean by that. This is only for gcc-cross and
gcc-cross-canadian. Anyone using those needs to deal with cross issues
regardless.

if you do not pass the right linker flags from compiler driver and also
>> ignore
>> the LDFLAGS then you now have a safe pass for the app to build without
>> GNU hash
>> while I understand it will spread the external toolchain’s pains into
>> internal toolchain
>> I fail to understand the benefit of doing this otherwise.
>
>
> Silently ignoring the fact that recipes ignore LDFLAGS is not good default
> behavior, and this is precisely what oe-core is doing today. If you know of
> a better way to detect that in another QA check, I'm certainly open to
> hearing it.
>
>
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in
> final ELF, may be adding a QA check for that would be enough ?
>

I don't understand what you mean by this. I don't see how you'd be able to
distinguish between a gnu.hash used because of the toolchain defaults and a
gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be
able to detect the lack of the latter without this patch.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 4716 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 3900 bytes --]


> On May 2, 2016, at 7:53 PM, Christopher Larson <kergoth@gmail.com> wrote:
> 
> 
> 
> On Mon, May 2, 2016 at 9:37 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> 
>> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com <mailto:kergoth@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
>> 
>> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com <mailto:kergoth@gmail.com>> wrote:
>> >
>> > From: Christopher Larson <chris_larson@mentor.com <mailto:chris_larson@mentor.com>>
>> >
>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
>> > this in the toolchain, while convenient, actually hides bugs, as a failure to
>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
>> > poison the sysroot -- rather than relying on the default, notice right away if
>> > somoeone isn't obeying the needed flags.
>> >
>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
>> > which is what's often seen with external toolchains. This brings us all on the
>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>> >
>> 
>> 
>> Default or gnu linkers is to use sysv for legacy reasons and by passing this option
>> to configuring the toolchain we want to make sure that components are using sane defaults
>> even if they have not configured these options.
>> 
>> But that's not what we want. We want to know when we're not passing arguments we need to be passing. For example, the sysroot is poisoned today, so we *know* when the user is trying to run it without --sysroot=.
> 
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get into same situations.
> as an application writer I may not be interested in using cross compilation specific nuances.  We may not
> be able to solve it completely
> 
> 
> I'm not sure what you mean by that. This is only for gcc-cross and gcc-cross-canadian. Anyone using those needs to deal with cross issues regardless.

I was taking a application developers point of view. not a system integrators or OE build masters. applications are supposed to work on all kind of env
and cross build env is one of them which large app developer community may not use as primary environment for development.

> 
>> if you do not pass the right linker flags from compiler driver and also ignore
>> the LDFLAGS then you now have a safe pass for the app to build without GNU hash
>> while I understand it will spread the external toolchain’s pains into internal toolchain
>> I fail to understand the benefit of doing this otherwise.
>> 
>> Silently ignoring the fact that recipes ignore LDFLAGS is not good default behavior, and this is precisely what oe-core is doing today. If you know of a better way to detect that in another QA check, I'm certainly open to hearing it.
> 
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in final ELF, may be adding a QA check for that would be enough ?
> 
> I don't understand what you mean by this. I don't see how you'd be able to distinguish between a gnu.hash used because of the toolchain defaults and a gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be able to detect the lack of the latter without this patch.

I thought you were looking for ways to detect if hash styles are mixed or not conforming to default for a given architecture. If the end binary is getting build as expected
and we are able to detect if it does not, then it won’t matter if the setting came from LDFLAGS or CFLAFS or implicit defaults.

> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics


[-- Attachment #1.2: Type: text/html, Size: 6877 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 4449 bytes --]

On Tue, May 3, 2016 at 3:01 AM, Khem Raj <raj.khem@gmail.com> wrote:

>
> On May 2, 2016, at 7:53 PM, Christopher Larson <kergoth@gmail.com> wrote:
>
>
>
> On Mon, May 2, 2016 at 9:37 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com> wrote:
>>
>>
>>
>> On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>>
>>> > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com>
>>> wrote:
>>> >
>>> > From: Christopher Larson <chris_larson@mentor.com>
>>> >
>>> > We explicitly set the hash style to gnu in our LDFLAGS. Setting the
>>> default to
>>> > this in the toolchain, while convenient, actually hides bugs, as a
>>> failure to
>>> > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to
>>> how we
>>> > poison the sysroot -- rather than relying on the default, notice right
>>> away if
>>> > somoeone isn't obeying the needed flags.
>>> >
>>> > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>>> failure,
>>> > which is what's often seen with external toolchains. This brings us
>>> all on the
>>> > same page, and makes sure a failure to obey LDFLAGS is seen early.
>>> >
>>>
>>>
>>> Default or gnu linkers is to use sysv for legacy reasons and by passing
>>> this option
>>> to configuring the toolchain we want to make sure that components are
>>> using sane defaults
>>> even if they have not configured these options.
>>>
>>
>> But that's not what we want. We want to know when we're not passing
>> arguments we need to be passing. For example, the sysroot is poisoned
>> today, so we *know* when the user is trying to run it without --sysroot=.
>>
>>
>> application makefiles can ignore environment e.g. CC, CXX, LD etc and get
>> into same situations.
>> as an application writer I may not be interested in using cross
>> compilation specific nuances.  We may not
>> be able to solve it completely
>>
>
>
> I'm not sure what you mean by that. This is only for gcc-cross and
> gcc-cross-canadian. Anyone using those needs to deal with cross issues
> regardless.
>
>
> I was taking a application developers point of view. not a system
> integrators or OE build masters. applications are supposed to work on all
> kind of env
> and cross build env is one of them which large app developer community may
> not use as primary environment for development.
>
>
> if you do not pass the right linker flags from compiler driver and also
>>> ignore
>>> the LDFLAGS then you now have a safe pass for the app to build without
>>> GNU hash
>>> while I understand it will spread the external toolchain’s pains into
>>> internal toolchain
>>> I fail to understand the benefit of doing this otherwise.
>>
>>
>> Silently ignoring the fact that recipes ignore LDFLAGS is not good
>> default behavior, and this is precisely what oe-core is doing today. If you
>> know of a better way to detect that in another QA check, I'm certainly open
>> to hearing it.
>>
>>
>> linker would emit .hash for sysv and .gnu.hash section for gnu hash in
>> final ELF, may be adding a QA check for that would be enough ?
>>
>
> I don't understand what you mean by this. I don't see how you'd be able to
> distinguish between a gnu.hash used because of the toolchain defaults and a
> gnu.hash used because it obeyed LDFLAGS, which is what you'd need to be
> able to detect the lack of the latter without this patch.
>
>
> I thought you were looking for ways to detect if hash styles are mixed or
> not conforming to default for a given architecture. If the end binary is
> getting build as expected
> and we are able to detect if it does not, then it won’t matter if the
> setting came from LDFLAGS or CFLAFS or implicit defaults.
>

No, that's exactly the point. Recipes have clear brokenness, not obeying
LDFLAGS, which is a clear correctness bug, and there's no easy way to
detect that if the toolchain sets the gnu hash style by default.

The only ones spotting these common, clear bugs are those using external
toolchains. The internal toolchain builds are ignoring these bugs by
letting the toolchain set the default regardless of whether it obeys
LDFLAGS or not.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 6635 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]

On Mon, May 02, 2016 at 02:37:43PM -0700, Khem Raj wrote:
> 
> > On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com> wrote:
> > 
> > 
> > 
> > On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> > 
> > > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com <mailto:kergoth@gmail.com>> wrote:
> > >
> > > From: Christopher Larson <chris_larson@mentor.com <mailto:chris_larson@mentor.com>>
> > >
> > > We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
> > > this in the toolchain, while convenient, actually hides bugs, as a failure to
> > > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> > > poison the sysroot -- rather than relying on the default, notice right away if
> > > somoeone isn't obeying the needed flags.
> > >
> > > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> > > which is what's often seen with external toolchains. This brings us all on the
> > > same page, and makes sure a failure to obey LDFLAGS is seen early.
> > >
> > 
> > 
> > Default or gnu linkers is to use sysv for legacy reasons and by passing this option
> > to configuring the toolchain we want to make sure that components are using sane defaults
> > even if they have not configured these options.
> > 
> > But that's not what we want. We want to know when we're not passing arguments we need to be passing. For example, the sysroot is poisoned today, so we *know* when the user is trying to run it without --sysroot=.
> 
> application makefiles can ignore environment e.g. CC, CXX, LD etc and get into same situations.
> as an application writer I may not be interested in using cross compilation specific nuances.  We may not
]> be able to solve it completely
> 
> > 
> > if you do not pass the right linker flags from compiler driver and also ignore
> > the LDFLAGS then you now have a safe pass for the app to build without GNU hash
> > while I understand it will spread the external toolchain’s pains into internal toolchain
> > I fail to understand the benefit of doing this otherwise.
> > 
> > Silently ignoring the fact that recipes ignore LDFLAGS is not good default behavior, and this is precisely what oe-core is doing today. If you know of a better way to detect that in another QA check, I'm certainly open to hearing it.
> 
> linker would emit .hash for sysv and .gnu.hash section for gnu hash in final ELF, may be adding a QA check for that would be enough ?

But that doesn't detect if it was set to gnu thanks to respecting
LDFLAGS or thanks to gnu being the default in oe-core built toolchain
(from --with-linker-hash-style) - which means that builds with
external toolchain are still affected if they don't use
--with-linker-hash-style=gnu.

After fixing couple recipes used by our internal builds (which are
using external toolchain) and wondering why nobody else reported
those I agree with Chris, that to detect this early (with current
QA check which already reports when the used hash style doesn't match
with LDFLAGS).

It would be nice to really poison the value if possible
--with-linker-hash-style=YOU_NEED_TO_RESPECT_LDFLAGS
to cause linker call to fail when someone is using oe-core toolchain
outside OE itself (so might ignore LDFLAGS, but without running the
QA check).

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Anders Darander]

* Martin Jansa <martin.jansa@gmail.com> [160503 10:08]:

> It would be nice to really poison the value if possible
> --with-linker-hash-style=YOU_NEED_TO_RESPECT_LDFLAGS
> to cause linker call to fail when someone is using oe-core toolchain
> outside OE itself (so might ignore LDFLAGS, but without running the
> QA check).

This sounds like a nice idea; making it comparible to how the sysroot is
poisoned.

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tue, May 3, 2016 at 9:11 AM, Anders Darander <anders@chargestorm.se>
wrote:

> * Martin Jansa <martin.jansa@gmail.com> [160503 10:08]:
>
> > It would be nice to really poison the value if possible
> > --with-linker-hash-style=YOU_NEED_TO_RESPECT_LDFLAGS
> > to cause linker call to fail when someone is using oe-core toolchain
> > outside OE itself (so might ignore LDFLAGS, but without running the
> > QA check).
>
> This sounds like a nice idea; making it comparible to how the sysroot is
> poisoned.
>

Doesn't look like that's allowed, the argument only allows specific styles.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1312 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Denys Dmytriyenko]

On Tue, May 03, 2016 at 10:09:13AM +0200, Martin Jansa wrote:
> On Mon, May 02, 2016 at 02:37:43PM -0700, Khem Raj wrote:
> > 
> > > On May 2, 2016, at 1:37 PM, Christopher Larson <kergoth@gmail.com> wrote:
> > > 
> > > 
> > > 
> > > On Mon, May 2, 2016 at 8:34 PM, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> > > 
> > > > On May 2, 2016, at 1:09 PM, Christopher Larson <kergoth@gmail.com <mailto:kergoth@gmail.com>> wrote:
> > > >
> > > > From: Christopher Larson <chris_larson@mentor.com <mailto:chris_larson@mentor.com>>
> > > >
> > > > We explicitly set the hash style to gnu in our LDFLAGS. Setting the default to
> > > > this in the toolchain, while convenient, actually hides bugs, as a failure to
> > > > obey LDFLAGS isn't noticed. By removing this, it's not dissimilar to how we
> > > > poison the sysroot -- rather than relying on the default, notice right away if
> > > > somoeone isn't obeying the needed flags.
> > > >
> > > > This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
> > > > which is what's often seen with external toolchains. This brings us all on the
> > > > same page, and makes sure a failure to obey LDFLAGS is seen early.
> > > >
> > > 
> > > 
> > > Default or gnu linkers is to use sysv for legacy reasons and by passing this option
> > > to configuring the toolchain we want to make sure that components are using sane defaults
> > > even if they have not configured these options.
> > > 
> > > But that's not what we want. We want to know when we're not passing arguments we need to be passing. For example, the sysroot is poisoned today, so we *know* when the user is trying to run it without --sysroot=.
> > 
> > application makefiles can ignore environment e.g. CC, CXX, LD etc and get into same situations.
> > as an application writer I may not be interested in using cross compilation specific nuances.  We may not
> ]> be able to solve it completely
> > 
> > > 
> > > if you do not pass the right linker flags from compiler driver and also ignore
> > > the LDFLAGS then you now have a safe pass for the app to build without GNU hash
> > > while I understand it will spread the external toolchain’s pains into internal toolchain
> > > I fail to understand the benefit of doing this otherwise.
> > > 
> > > Silently ignoring the fact that recipes ignore LDFLAGS is not good default behavior, and this is precisely what oe-core is doing today. If you know of a better way to detect that in another QA check, I'm certainly open to hearing it.
> > 
> > linker would emit .hash for sysv and .gnu.hash section for gnu hash in final ELF, may be adding a QA check for that would be enough ?
> 
> But that doesn't detect if it was set to gnu thanks to respecting
> LDFLAGS or thanks to gnu being the default in oe-core built toolchain
> (from --with-linker-hash-style) - which means that builds with
> external toolchain are still affected if they don't use
> --with-linker-hash-style=gnu.
> 
> After fixing couple recipes used by our internal builds (which are
> using external toolchain) and wondering why nobody else reported
> those I agree with Chris, that to detect this early (with current
> QA check which already reports when the used hash style doesn't match
> with LDFLAGS).

I'd like to back Chris and Martin here - using external toolchain as well and 
seeing few GNU_HASH warnings. Some warning are ours (too busy/lazy to fix now) 
but some are upstream recipes, maybe it's time to clean them up collectively?

-- 
Denys


> It would be nice to really poison the value if possible
> --with-linker-hash-style=YOU_NEED_TO_RESPECT_LDFLAGS
> to cause linker call to fail when someone is using oe-core toolchain
> outside OE itself (so might ignore LDFLAGS, but without running the
> QA check).
> 
> Regards,
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com



> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On 2 May 2016 at 21:09, Christopher Larson <kergoth@gmail.com> wrote:

> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
> failure,
> which is what's often seen with external toolchains. This brings us all on
> the
> same page, and makes sure a failure to obey LDFLAGS is seen early.
>

I love the idea, but:

ERROR: libgcc-5.3.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf
binary:
'/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/libgcc/5.3.0-r0/packages-split/libgcc/lib/libgcc_s.so.1'
[ldflags]

Ross

[-- Attachment #2: Type: text/html, Size: 1026 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On Wed, May 4, 2016 at 2:01 PM, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 2 May 2016 at 21:09, Christopher Larson <kergoth@gmail.com> wrote:
>
>> This will result in a failure to obey LDFLAGS causing a GNU_HASH QA
>> failure,
>> which is what's often seen with external toolchains. This brings us all
>> on the
>> same page, and makes sure a failure to obey LDFLAGS is seen early.
>>
>
> I love the idea, but:
>
> ERROR: libgcc-5.3.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf
> binary:
> '/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/libgcc/5.3.0-r0/packages-split/libgcc/lib/libgcc_s.so.1'
> [ldflags]
>
> Ross
>

No idea how I missed this, since I did test builds, but I'll submit a patch
to oe-core shortly. Thanks :)
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1803 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Bystricky, Juro]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Two additional GNU_HASH related errors were observed (breaking some builds) that seem to be related to the patch:

ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
No GNU_HASH in the elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
No GNU_HASH in the elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors. Please consider fixing them.


ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1-r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]

Juro



From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Christopher Larson
Sent: Wednesday, May 4, 2016 12:11 PM
To: Burton, Ross <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style



On Wed, May 4, 2016 at 2:01 PM, Burton, Ross <ross.burton@intel.com<mailto:ross.burton@intel.com>> wrote:

On 2 May 2016 at 21:09, Christopher Larson <kergoth@gmail.com<mailto:kergoth@gmail.com>> wrote:
This will result in a failure to obey LDFLAGS causing a GNU_HASH QA failure,
which is what's often seen with external toolchains. This brings us all on the
same page, and makes sure a failure to obey LDFLAGS is seen early.

I love the idea, but:

ERROR: libgcc-5.3.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/libgcc/5.3.0-r0/packages-split/libgcc/lib/libgcc_s.so.1' [ldflags]

Ross

No idea how I missed this, since I did test builds, but I'll submit a patch to oe-core shortly. Thanks :)
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 7750 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <juro.bystricky@intel.com>
wrote:

> Two additional GNU_HASH related errors were observed (breaking some
> builds) that seem to be related to the patch:
>
>
>
> ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the elf
> binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
>
> No GNU_HASH in the elf binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
>
> No GNU_HASH in the elf binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/printenv'
> [ldflags]
>
> ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
>
>
>
>
>
> ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the elf
> binary:
> '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1-r0/packages-split/service/usr/sbin/skeleton-test'
> [ldflags]
>

Huh, I must not have had ptest enabled in my test builds. Thanks, will take
a look.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 3189 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Richard Purdie]

On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
> 
> 
> On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
> juro.bystricky@intel.com> wrote:
> > Two additional GNU_HASH related errors were observed (breaking some
> > builds) that seem to be related to the patch:
> >  
> > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
> > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
> > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
> > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > -autobuilder/yocto-worker/nightly-non
> > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
> > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > -autobuilder/yocto-worker/nightly-non
> > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
> > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
> > Please consider fixing them.
> >  
> >  
> > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
> > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
> > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
> > 
> Huh, I must not have had ptest enabled in my test builds. Thanks,
> will take a look.

The above is an older gplv2 recipe failure which is probably why you
didn't see it.

I'm afraid there were more. pseudo:

https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
ds/747/steps/BuildImages_1/logs/stdio

qt-x11-free:

https://autobuilder.yoctoproject.or
g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
ds/744/steps/BuildImages/logs/stdio
https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
uilds/779/steps/BuildImages/logs/stdio

service in qa-skeleton:

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
builds/753/steps/BuildImages/logs/stdio

ruby and mkefiimage:

https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
s/104/steps/BuildImages/logs/stdio

(selftest also showed mkefimage failure)

Cheers,

Richard

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

On Mon, May 9, 2016 at 3:16 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
> >
> >
> > On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
> > juro.bystricky@intel.com> wrote:
> > > Two additional GNU_HASH related errors were observed (breaking some
> > > builds) that seem to be related to the patch:
> > >
> > > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
> > > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > > -autobuilder/yocto-worker/nightly-non
> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
> > > -autobuilder/yocto-worker/nightly-non
> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
> > > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
> > > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
> > > Please consider fixing them.
> > >
> > >
> > > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
> > > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
> > > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
> > >
> > Huh, I must not have had ptest enabled in my test builds. Thanks,
> > will take a look.
>
> The above is an older gplv2 recipe failure which is probably why you
> didn't see it.
>
> I'm afraid there were more. pseudo:
>
> https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
> ds/747/steps/BuildImages_1/logs/stdio
>
> qt-x11-free:
>
> https://autobuilder.yoctoproject.or
> g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
> ds/744/steps/BuildImages/logs/stdio
> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
> uilds/779/steps/BuildImages/logs/stdio
>
> service in qa-skeleton:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
> builds/753/steps/BuildImages/logs/stdio
>
> ruby and mkefiimage:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
> s/104/steps/BuildImages/logs/stdio
>
> (selftest also showed mkefimage failure)


I'll take a look asap, unless someone else gets to it first. As mentioned,
ruby, mkelfimage and one other were already on the list as of last thursday.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 4674 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 3903 bytes --]

On Mon, May 9, 2016 at 3:34 PM, Christopher Larson <kergoth@gmail.com>
wrote:

> On Mon, May 9, 2016 at 3:16 PM, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> On Mon, 2016-05-09 at 09:39 -0700, Christopher Larson wrote:
>> >
>> >
>> > On Mon, May 9, 2016 at 9:35 AM, Bystricky, Juro <
>> > juro.bystricky@intel.com> wrote:
>> > > Two additional GNU_HASH related errors were observed (breaking some
>> > > builds) that seem to be related to the patch:
>> > >
>> > > ERROR: bash-3.2.48-r11 do_package_qa: QA Issue: No GNU_HASH in the
>> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
>> > > -non-gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48
>> > > -r11/packages-split/bash-ptest/usr/lib/bash/ptest/tests/recho'
>> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
>> > > -autobuilder/yocto-worker/nightly-non
>> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
>> > > -split/bash-ptest/usr/lib/bash/ptest/tests/zecho'
>> > > No GNU_HASH in the elf binary: '/home/pokybuild/yocto
>> > > -autobuilder/yocto-worker/nightly-non
>> > > -gpl3/build/build/tmp/work/i586-poky-linux/bash/3.2.48-r11/packages
>> > > -split/bash-ptest/usr/lib/bash/ptest/tests/printenv' [ldflags]
>> > > ERROR: bash-3.2.48-r11 do_package_qa: QA run found fatal errors.
>> > > Please consider fixing them.
>> > >
>> > >
>> > > ERROR: service-0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
>> > > elf binary: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly
>> > > -qa-skeleton/build/build/tmp/work/core2-64-poky-linux/service/0.1
>> > > -r0/packages-split/service/usr/sbin/skeleton-test' [ldflags]
>> > >
>> > Huh, I must not have had ptest enabled in my test builds. Thanks,
>> > will take a look.
>>
>> The above is an older gplv2 recipe failure which is probably why you
>> didn't see it.
>>
>> I'm afraid there were more. pseudo:
>>
>> https://autobuilder.yoctoproject.org/main/builders/build-appliance/buil
>> ds/747/steps/BuildImages_1/logs/stdio
>> <https://autobuilder.yoctoproject.org/main/builders/build-appliance/builds/747/steps/BuildImages_1/logs/stdio>
>>
>> qt-x11-free:
>>
>> https://autobuilder.yoctoproject.or
>> g/main/builders/nightly-arm-lsb/builds/734/steps/BuildImages/logs/stdio
>> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/buil
>> ds/744/steps/BuildImages/logs/stdio
>> <https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/builds/744/steps/BuildImages/logs/stdio>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/b
>> uilds/779/steps/BuildImages/logs/stdio
>> <https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-lsb/builds/779/steps/BuildImages/logs/stdio>
>>
>> service in qa-skeleton:
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/
>> builds/753/steps/BuildImages/logs/stdio
>> <https://autobuilder.yoctoproject.org/main/builders/nightly-qa-skeleton/builds/753/steps/BuildImages/logs/stdio>
>>
>> ruby and mkefiimage:
>>
>> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/build
>> s/104/steps/BuildImages/logs/stdio
>> <https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/104/steps/BuildImages/logs/stdio>
>>
>> (selftest also showed mkefimage failure)
>
>
> I'll take a look asap, unless someone else gets to it first. As mentioned,
> ruby, mkelfimage and one other were already on the list as of last thursday.
>

I have to say, I didn't realize oe-core patches require testing with
meta-qt3. I can't remember the last time I touched qt that old. I'll have
to add more non-core layers to my local testing in the future.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 5228 bytes --]

Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style

[Richard Purdie]

On Mon, 2016-05-09 at 15:41 -0700, Christopher Larson wrote:

> I have to say, I didn't realize oe-core patches require testing with
> meta-qt3. I can't remember the last time I touched qt that old. I'll
> have to add more non-core layers to my local testing in the future.

The version of lsb we have requires qt3 so it gets pulled into poky-lsb
only. Personally, I can't wait to upgrade lsb and then drop it. I'm
hoping that happens this cycle, finally.

Cheers,

Richard