Re: [PATCH 5/6] musl: Update to latest

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2017-03-20 at 10:32 +0200, Jussi Kukkonen wrote:
> 
> On 15 March 2017 at 01:35, Khem Raj <raj.khem@gmail.com> 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"
> ?
> 
> 
> 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.