On Thu, Apr 9, 2020 at 2:47 AM Richard Purdie <[email protected]> wrote: > > On Wed, 2020-04-08 at 16:45 -0700, Khem Raj wrote: > > On Wed, Apr 8, 2020 at 4:18 PM Richard Purdie > > <[email protected]> wrote: > > > As discussed in the bugzilla entry, musl is not compatible with > > > multilibs > > > and has no plans to support this. Therefore tell users this from > > > the > > > recipe rather than letting them run into build failures. > > > > > > > I dont think thats the case anymore, I have sent patches to fix > > multilib on musl. this seems a broad brush. What are you trying to > > fix ? > > The bug said we don't support multilib and musl and the code clearly > currently doesn't, so this patch was to make the situation clearer to > users. > > Based on the need for your patch and other patches, its clear that musl > and multilib doesn't work as things stand today. > > The question becomes whether we want to support that? Do we want/need > to add automated tests for it? > > We've built 3.1 rc2 which is in QA so this wasn't going into the > release, maybe the point release, or if we rebuild for some reason. I > do want to do something with the bug. If we want to enable multilib > with musl that would be a 3.2 activity. > > Perhaps we should merge this change, then remove it when the other > issues are fixed?
I tthink fixing musl for a mixed mulilib is a bit invasive at this time of release so agreed on that. however this will disable a usecase which is valid for musl systems 64bit kernel + 32bit-only-userspace. So I am a bit torn here to disable it completely. perhaps a parse warning might be good compromise. > > Cheers, > > Richard > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#137153): https://lists.openembedded.org/g/openembedded-core/message/137153 Mute This Topic: https://lists.openembedded.org/mt/72886268/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
