On Fri, Feb 14, 2020 at 5:21 PM Khem Raj <raj.k...@gmail.com> wrote: > > On Fri, Feb 14, 2020 at 5:02 PM Andre McCurdy <armccu...@gmail.com> wrote: > > > > On Fri, Feb 14, 2020 at 7:42 AM Khem Raj <raj.k...@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.k...@gmail.com>> Signed-off-by: Richard > > > Purdie <richard.pur...@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@lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
