* [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style @ 2016-05-02 20:09 Christopher Larson 2016-05-02 20:34 ` Khem Raj 2016-05-04 14:01 ` Burton, Ross 0 siblings, 2 replies; 19+ messages in thread From: Christopher Larson @ 2016-05-02 20:09 UTC (permalink / raw) To: openembedded-core; +Cc: 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 20:09 [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style Christopher Larson @ 2016-05-02 20:34 ` Khem Raj 2016-05-02 20:37 ` Christopher Larson 2016-05-04 14:01 ` Burton, Ross 1 sibling, 1 reply; 19+ messages in thread From: Khem Raj @ 2016-05-02 20:34 UTC (permalink / raw) To: Christopher Larson; +Cc: Christopher Larson, openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 20:34 ` Khem Raj @ 2016-05-02 20:37 ` Christopher Larson 2016-05-02 21:37 ` Khem Raj 0 siblings, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-02 20:37 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 20:37 ` Christopher Larson @ 2016-05-02 21:37 ` Khem Raj 2016-05-03 2:53 ` Christopher Larson 2016-05-03 8:09 ` Martin Jansa 0 siblings, 2 replies; 19+ messages in thread From: Khem Raj @ 2016-05-02 21:37 UTC (permalink / raw) To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 21:37 ` Khem Raj @ 2016-05-03 2:53 ` Christopher Larson 2016-05-03 3:01 ` Khem Raj 2016-05-03 8:09 ` Martin Jansa 1 sibling, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-03 2:53 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-03 2:53 ` Christopher Larson @ 2016-05-03 3:01 ` Khem Raj 2016-05-03 3:05 ` Christopher Larson 0 siblings, 1 reply; 19+ messages in thread From: Khem Raj @ 2016-05-03 3:01 UTC (permalink / raw) To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-03 3:01 ` Khem Raj @ 2016-05-03 3:05 ` Christopher Larson 0 siblings, 0 replies; 19+ messages in thread From: Christopher Larson @ 2016-05-03 3:05 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 21:37 ` Khem Raj 2016-05-03 2:53 ` Christopher Larson @ 2016-05-03 8:09 ` Martin Jansa 2016-05-03 9:11 ` Anders Darander 2016-05-03 18:13 ` Denys Dmytriyenko 1 sibling, 2 replies; 19+ messages in thread From: Martin Jansa @ 2016-05-03 8:09 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-03 8:09 ` Martin Jansa @ 2016-05-03 9:11 ` Anders Darander 2016-05-03 16:07 ` Christopher Larson 2016-05-03 18:13 ` Denys Dmytriyenko 1 sibling, 1 reply; 19+ messages in thread From: Anders Darander @ 2016-05-03 9:11 UTC (permalink / raw) To: openembedded-core * 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-03 9:11 ` Anders Darander @ 2016-05-03 16:07 ` Christopher Larson 0 siblings, 0 replies; 19+ messages in thread From: Christopher Larson @ 2016-05-03 16:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-03 8:09 ` Martin Jansa 2016-05-03 9:11 ` Anders Darander @ 2016-05-03 18:13 ` Denys Dmytriyenko 1 sibling, 0 replies; 19+ messages in thread From: Denys Dmytriyenko @ 2016-05-03 18:13 UTC (permalink / raw) To: Martin Jansa; +Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-02 20:09 [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style Christopher Larson 2016-05-02 20:34 ` Khem Raj @ 2016-05-04 14:01 ` Burton, Ross 2016-05-04 19:11 ` Christopher Larson 1 sibling, 1 reply; 19+ messages in thread From: Burton, Ross @ 2016-05-04 14:01 UTC (permalink / raw) To: Christopher Larson; +Cc: Christopher Larson, OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-04 14:01 ` Burton, Ross @ 2016-05-04 19:11 ` Christopher Larson 2016-05-09 16:35 ` Bystricky, Juro 0 siblings, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-04 19:11 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-04 19:11 ` Christopher Larson @ 2016-05-09 16:35 ` Bystricky, Juro 2016-05-09 16:39 ` Christopher Larson 0 siblings, 1 reply; 19+ messages in thread From: Bystricky, Juro @ 2016-05-09 16:35 UTC (permalink / raw) To: Christopher Larson, Burton, Ross; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-09 16:35 ` Bystricky, Juro @ 2016-05-09 16:39 ` Christopher Larson 2016-05-09 22:16 ` Richard Purdie 0 siblings, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-09 16:39 UTC (permalink / raw) To: Bystricky, Juro; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-09 16:39 ` Christopher Larson @ 2016-05-09 22:16 ` Richard Purdie 2016-05-09 22:34 ` Christopher Larson 0 siblings, 1 reply; 19+ messages in thread From: Richard Purdie @ 2016-05-09 22:16 UTC (permalink / raw) To: Christopher Larson, Bystricky, Juro; +Cc: OE-core 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-09 22:16 ` Richard Purdie @ 2016-05-09 22:34 ` Christopher Larson 2016-05-09 22:41 ` Christopher Larson 0 siblings, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-09 22:34 UTC (permalink / raw) To: Richard Purdie; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-09 22:34 ` Christopher Larson @ 2016-05-09 22:41 ` Christopher Larson 2016-05-09 22:54 ` Richard Purdie 0 siblings, 1 reply; 19+ messages in thread From: Christopher Larson @ 2016-05-09 22:41 UTC (permalink / raw) To: Richard Purdie; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style 2016-05-09 22:41 ` Christopher Larson @ 2016-05-09 22:54 ` Richard Purdie 0 siblings, 0 replies; 19+ messages in thread From: Richard Purdie @ 2016-05-09 22:54 UTC (permalink / raw) To: Christopher Larson; +Cc: OE-core 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-05-09 22:54 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-02 20:09 [master][PATCH] gcc-cross{, -canadian}: remove --with-linker-hash-style Christopher Larson 2016-05-02 20:34 ` Khem Raj 2016-05-02 20:37 ` Christopher Larson 2016-05-02 21:37 ` Khem Raj 2016-05-03 2:53 ` Christopher Larson 2016-05-03 3:01 ` Khem Raj 2016-05-03 3:05 ` Christopher Larson 2016-05-03 8:09 ` Martin Jansa 2016-05-03 9:11 ` Anders Darander 2016-05-03 16:07 ` Christopher Larson 2016-05-03 18:13 ` Denys Dmytriyenko 2016-05-04 14:01 ` Burton, Ross 2016-05-04 19:11 ` Christopher Larson 2016-05-09 16:35 ` Bystricky, Juro 2016-05-09 16:39 ` Christopher Larson 2016-05-09 22:16 ` Richard Purdie 2016-05-09 22:34 ` Christopher Larson 2016-05-09 22:41 ` Christopher Larson 2016-05-09 22:54 ` Richard Purdie
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.