recipes-core: Add musl OpenHarmony compatibility patches

Add OpenHarmony compatibility patches to musl. This is a port of the OpenHarmony 3.1 patches as found in https://gitlab.eclipse.org/esben/meta-openharmony/-/tree/wip/oh-3.1/recipes-core/musl commit d06ff8b5d165b862298a756799dbc641cb68b1c5 to current musl.

The patches should be harmless. Their effects:

• Add OpenHarmony's malloc hook mechanism
• Add stubs for mallinfo() and mallinfo2() [currently not implemented by musl]
• Mark memory allocated by musl malloc with PR_SET_VMA_ANON_NAME
• Add a gettid/pthread_gettid_np implementation
• Increase SHMLBA size
• Add namespaced dlopen APIs
• Implement sched_getparam(), sched_getscheduler() and sched_setscheduler() [Linux only]
• small tweaks and optimizations

The patches don't look like they will cause trouble.

If there is anything that uses mallinfo() or mallinfo2() with autoconf/cmake/meson checks (didn't find anything at a quick look), we might want to disable those stubs - not having those calls is preferable over having them return bogus values).

Signed-off-by: Bernhard Rosenkränzer bernhard.rosenkraenzer.ext@huawei.com

requested review from @esben

assigned to @bero

There's a few things that should probably be fixed (namespace pollution by #define cap, mallinfo/mallinfo2 not working, DOS style newlines in a few files, ...), but this should be a good starting point (let's get in sync with OH before fixing it)

mentioned in issue #91 (closed)

Do we really want to apply these patches unconditionally? By doing that, just adding oniro to a bitbake layer stack changes musl. I would think it would be less surprising if they were only selected when using appropriate Oniro distro configurations.

Good question. I initially decided to apply them unconditionally because the patch set is really small and shouldn't break anything. But we should probably conditionalize at least stuff like mallinfo()/mallinfo2(). Turns out this breaks ltp at least (because ltp assumes presence of mallinfo() also means presence of mallopt()). I think I'll split it into "good" and "questionable" parts...

I will still question if this is best practise in Yocto land, implicitly patching libc recipe with new features when adding a layer. Bugfixes is probably fine.

Maybe some more Yocto savvy than me can advice?

@bero so we're waiting for you to post a "good" MR and a separate one for "questionable" patches?

resolved all threads

mentioned in epic &88

added 79 commits

• 56e3d44e...85c0c66b - 78 commits from branch eclipse/oniro-core:kirkstone
• ca01220f - recipes-core: Add musl OpenHarmony compatibility patches

Compare with previous version