[OE-core] [PATCH 1/3] musl: Update to latest tip

[Andre McCurdy]

On Fri, Feb 14, 2020 at 5:21 PM Khem Raj <raj.khem at gmail.com> wrote:
>
> On Fri, Feb 14, 2020 at 5:02 PM Andre McCurdy <armccurdy at gmail.com> wrote:
> >
> > On Fri, Feb 14, 2020 at 7:42 AM Khem Raj <raj.khem at gmail.com> wrote:
> > >
> > > Detailed changelog is here [1]
> > >
> > > [1] https://git.musl-libc.org/cgit/musl/log/?qt=range&q=e6093b5a870a38ebfb3e54382acd48c698bde15d..a662220df547e5c2446518e74440a7d834f9ebe6
> >
> > Up to now, musl version updates have basically always just made things
> > better and there's never been a good reason not to switch to a new
> > musl release (in my own forks of oe-core I've updated both OE 2.7 and
> > OE 3.0 to the musl 1.1.24 release, etc).
> >
> > However, after 1.1.24, musl switches 32bit targets to a 64bit time_t
> > (in preparation for 2038) and from my initial testing that seems to be
> > a change which is going to cause a lot of problems (both build time
> > and run time) for proprietary components and BSPs etc which are only
> > ever used on a 32bit target. Anything open source is likely to have
> > been well tested on a 64bit target and so any assumptions about the
> > size of time_t will have been fixed long ago, but even then there's a
> > chance of problems (see recent fixes in oe-core for build time issues
> > in strace, systemd, busybox, etc. I guess that run time issues are
> > likely to emerge too as the latest musl snapshot gets more testing on
> > 32bit targets).
> >
> > Updating musl beyond 1.1.24 in oe-core probably needs some careful
> > consideration, especially just before OE 3.1 LTS.
>
> yes I am well aware of 64bit time_t changes, 1.25 should release well before
> 3.1 cut-off, musl maintainers are aware of it

Yes, I'm sure you're aware and that the musl maintainers are aware too
:-) It's end users of OE who perhaps haven't been given enough
warning.

> and we have been fixing buggy apps which have assumptions about
> the length of time_t, we would like to ship with 1.25 for 3.1
> so please report isssues if you find and we can work along with them

The issues I've seen are in a proprietary BSP, so reporting them here
wouldn't be appropriate. I'm already carrying ~300 patches to build
their code with OE 3.0 and musl 1.1.24 (which the BSP vendor has no
interesting in supporting) but the time_t issues may be pervasive
enough that the safest approach will be to go back to glibc and find
the code size savings elsewhere.

Anyway, my point is just to make it clear that this change in musl may
be a big deal for some end users even if it's a relative non-event for
oe-core.

> > (Note that the version of musl in oe-core master is already beyond
> > 1.1.24, so these comments don't apply specifically to this commit).
> >
> >
> > > Signed-off-by: Khem Raj <raj.khem at gmail.com>> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> > > ---
> > >  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 f4853b4f2e..b6ec6fe9af 100644
> > > --- a/meta/recipes-core/musl/musl_git.bb
> > > +++ b/meta/recipes-core/musl/musl_git.bb
> > > @@ -4,7 +4,7 @@
> > >  require musl.inc
> > >  inherit linuxloader
> > >
> > > -SRCREV = "e6093b5a870a38ebfb3e54382acd48c698bde15d"
> > > +SRCREV = "a662220df547e5c2446518e74440a7d834f9ebe6"
> > >
> > >  BASEVER = "1.1.24"
> > >
> > > --
> > > 2.25.0
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core at lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core