Re: [OE-core] [PATCH 5/6] musl: Update to latest
On Mon, Mar 20, 2017 at 1:32 AM, Jussi Kukkonenwrote: > > On 15 March 2017 at 01:35, Khem Raj wrote: >> >> Rich Felker (11): >> fix ld-behavior-dependent crash in ppc64 ldso startup >> rework ldso handling of global symbol table for consistency >> reorder addend handling before symbol lookup in relocation code >> emulate lazy relocation as deferrable relocation >> fix free of uninitialized buffer pointer on error in regexec >> in static dl_iterate_phdr, fix use of possibly-uninitialized aux >> data >> fix possible fd leak, unrestored cancellation state on dns socket >> fail >> fix wide scanf's use of a compound literal past its lifetime >> fix one-byte overflow in legacy getpass function >> avoid loading of multiple libc versions via explicit pathname >> remove unused refcnt field for shared libraries >> >> Szabolcs Nagy (1): >> treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym > > > > Could the relocation changes here be responsible for these ovmf build > failures: > "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation" > ? > Dont understand why musl would affect here. its using native gcc to build the artifacts its complaining about, > https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio > > > Jussi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/6] musl: Update to latest
On Mon, 2017-03-20 at 10:32 +0200, Jussi Kukkonen wrote: > > On 15 March 2017 at 01:35, Khem Rajwrote: > Rich Felker (11): > fix ld-behavior-dependent crash in ppc64 ldso startup > rework ldso handling of global symbol table for > consistency > reorder addend handling before symbol lookup in > relocation code > emulate lazy relocation as deferrable relocation > fix free of uninitialized buffer pointer on error in > regexec > in static dl_iterate_phdr, fix use of > possibly-uninitialized aux data > fix possible fd leak, unrestored cancellation state on > dns socket fail > fix wide scanf's use of a compound literal past its > lifetime > fix one-byte overflow in legacy getpass function > avoid loading of multiple libc versions via explicit > pathname > remove unused refcnt field for shared libraries > > Szabolcs Nagy (1): > treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in > find_sym > > > > > Could the relocation changes here be responsible for these ovmf build > failures: > "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation" > ? > > > https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio That looks like a good guess. I had tried to reproduce that error last week with poky/master-next, but somehow it didn't trigger in my local setup. I have no idea how to enhance ovmf such that can handle this, though. Holding back an update of musl until someone can figure it out does not very attractive. But nor is disabling the building of ovmf when musl is selected, because then the wic tests which rely on ovmf will fail or also need to get disabled. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/6] musl: Update to latest
On 15 March 2017 at 01:35, Khem Rajwrote: > Rich Felker (11): > fix ld-behavior-dependent crash in ppc64 ldso startup > rework ldso handling of global symbol table for consistency > reorder addend handling before symbol lookup in relocation code > emulate lazy relocation as deferrable relocation > fix free of uninitialized buffer pointer on error in regexec > in static dl_iterate_phdr, fix use of possibly-uninitialized aux data > fix possible fd leak, unrestored cancellation state on dns socket > fail > fix wide scanf's use of a compound literal past its lifetime > fix one-byte overflow in legacy getpass function > avoid loading of multiple libc versions via explicit pathname > remove unused refcnt field for shared libraries > > Szabolcs Nagy (1): > treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym > Could the relocation changes here be responsible for these ovmf build failures: "GenFw: ERROR 3000: Invalid ... unsupported ELF EM_386 relocation" ? https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio Jussi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] musl: Update to latest
Rich Felker (11): fix ld-behavior-dependent crash in ppc64 ldso startup rework ldso handling of global symbol table for consistency reorder addend handling before symbol lookup in relocation code emulate lazy relocation as deferrable relocation fix free of uninitialized buffer pointer on error in regexec in static dl_iterate_phdr, fix use of possibly-uninitialized aux data fix possible fd leak, unrestored cancellation state on dns socket fail fix wide scanf's use of a compound literal past its lifetime fix one-byte overflow in legacy getpass function avoid loading of multiple libc versions via explicit pathname remove unused refcnt field for shared libraries Szabolcs Nagy (1): treat STB_WEAK and STB_GNU_UNIQUE like STB_GLOBAL in find_sym Signed-off-by: Khem Raj--- meta/recipes-core/musl/musl_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index 7156669064..fa87d7d3e3 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -3,7 +3,7 @@ require musl.inc -SRCREV = "827c4e6fbe46142049ef3d8bcb8f35951712797d" +SRCREV = "cb525397bb053ea49cf160965477a17b17286eb3" PV = "1.1.16+git${SRCPV}" -- 2.12.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core