On Thu, Jul 29, 2021 at 6:54 AM Luca Boccassi <[email protected]> wrote: > > On Thu, 2021-07-29 at 14:49 +0100, Luca Boccassi wrote: > > On Thu, 2021-07-29 at 12:59 +0000, Khem Raj wrote: > > > Latest upgrade to 249 broke a working build on musl, this is incremental > > > fix to exisiting patches adapted to 249 release > > > > > > Signed-off-by: Khem Raj <[email protected]> > > > Cc: Luca Boccassi <[email protected]> > > > --- > > > ...002-don-t-use-glibc-specific-qsort_r.patch | 24 +-- > > > ...missing.h-check-for-missing-strndupa.patch | 173 +++++++++--------- > > > .../0006-Include-netinet-if_ether.h.patch | 147 ++++++++------- > > > ...OB_BRACE-and-GLOB_ALTDIRFUNC-is-not-.patch | 20 +- > > > ...T_SYMLINK_NOFOLLOW-flag-to-faccessat.patch | 14 +- > > > ...-not-disable-buffer-in-writing-files.patch | 143 ++++++--------- > > > .../systemd/0026-Handle-missing-gshadow.patch | 18 +- > > > 7 files changed, 247 insertions(+), 292 deletions(-) > > > > > > > Having a look at the patches, a few comments: > > > > - 0001-test-parse-argument-Include-signal.h.patch was merged upstream, > > but never removed, I think because it was refactored so it applies > > cleanly and doesn't raise errors?
seems so. > > > > - 0005-src-basic-missing.h-check-for-missing-strndupa.patch this is > > massive and will keep growing and breaking the build, wouldn't it be > > better to just implement strndupa in musl? Even out-of-tree it sounds > > like it would be easier to maintain than this > > > > - 0006-Include-netinet-if_ether.h.patch sounds like it should be doable > > in a way that is compatible with both glibc and musl, and thus could be > > upstreamed? I think it could be, although systemd has started caching some of these system headers in its own sources which is also troublesome. So overall it has to be addressed with a bit wider scope. > > > > - 0010-Use-uintmax_t-for-handling-rlim_t.patch can be upstreamed but > > needs to be reworked slightly as explained in > > https://github.com/systemd/systemd/pull/7199#issuecomment-358268647 > > which seems worth doing to me > > perhaps yes, although I was not sure what it would be for a patch. > > - 0012-don-t-pass-AT_SYMLINK_NOFOLLOW-flag-to-faccessat.patch I find > > quite worrying, as it fundamentally changes access patterns, some of > > which are done for security reasons. At best, this will cause > > completely different runtime behaviours for the same filesystem > > depending on the libc implementation, which doesn't sound great? > > > > - 0016-Hide-__start_BUS_ERROR_MAP-and-__stop_BUS_ERROR_MAP.patch sounds > > like a genuine bug, have you tried upstreaming it? > > It was part of a cumulative patchset to support musl which was not accepted but I can try this patch alone. > > - 0019-Handle-missing-LOCK_EX.patch I see no problem upstreaming this OK > > > > - 0028-missing_syscall.h-Define-MIPS-ABI-defines-for-musl.patch should > > also be fine to upstream I think, in src/basic/missing_syscall_def.h OK > > Also isn't 0001-binfmt-Don-t-install-dependency-links-at-install- > tim.patch doable with two drop-ins and a post-install adjustment in the > recipe, rather than with a patch? > > This also sounds like a good candidate for a drop-in, doesn't seem > generally applicable to me: > > https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=f65757ad1791a46cc210141c84ccc51552171e98 > surely although its generic and not musl specific perhaps deal with it separately. > -- > Kind regards, > Luca Boccassi
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154252): https://lists.openembedded.org/g/openembedded-core/message/154252 Mute This Topic: https://lists.openembedded.org/mt/84490599/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
