An upstream patch (oe-core) doesn't apply cleanly on the musl version
openharmony is using. Refresh to fix the associated build warnings.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>

This reverts commit 7400fb56.

This change is not needed anymore as it turns out that the error it was
supposed to fix only appeared on my local builds. The error simply
disappeared after a fresh full rebuild.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

This should be dropped once meta-openharmony is upgraded to a musl libc
version that includes qsort_r() function.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Instead of hardcoding an `openharmony` override, this introduce an
`openharmony` distro feature which (when enabled) will add a
`df-openharmony` override.

The `openharmony` distro feature will also gate the `openharmony-3.0`
and `openharmony-3.1` overrides, so they are only active when `openharmony`
is enabled.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This explicitly adds libfts.a to the package files and fixes an error
openharmony-standard do_package() that depends on libfts.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Only those licenses that are explicitly mention in the SPDX headers in the
repository are allowed to have license text files present. That means, that in
the LICENSE directory we can only have licenses for meta-data files and not
licenses for packages that this meta-data is used to build.

Signed-off-by: Robert Drab <robert.drab@huawei.com>

This allows building OpenHarmony compatible musl using any distro configuration
which enables "openharmony" in its DISTROOVERRIDES.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

With this change, the OpenHarmomy lib paths are now added to
/etc/ld-musl-${MUSL_LDSO_ARCH}.path based on the content of the distro
variable MUSL_LDSO_PATHS.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

This adds /usr/lib/module/* subfolders to lib search path so OpenHarmony
components are able to find libraries they need.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

OpenHarmony stores libraries in both /system/lib and /system/lib/module, and
needs to be able to find them.  With /system/lib being a symlink to /usr/lib, we
need to add /usr/lib/module to search path.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

With OpenHarmony tests using some of our busybox commands, this should help us
not having to fight quite as much fallout from busybox CLI being different
from normal (and/or toybox) CLI.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Esben Haabendal authored 2 years ago and Thierry Escande committed 2 years ago

This moves the public headers defining the interface to the OpenHarmony
musl (malloc/free) hooks into the correct place, so they get installed as public
headers.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Esben Haabendal authored 2 years ago and Thierry Escande committed 2 years ago

This adds the musl patches based on the OpenHarmony-v3.1-Release tag in
the OpenHarmony musl repository.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>

Thierry Escande authored 2 years ago and Esben Haabendal committed 2 years ago

This change moves the hunk for the file sys/capabilty.h into its own
patch file so it can be ignored.  We will be using the sys/capability.h
header file from libcap instead, to allow using libcap also.

Signed-off-by: Thierry Escande <thierry.escande@huawei.com>
Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

The openharmony-linux-user.patch extracted from OpenHarmony only included
modified files, not new files.

With gettid.c being included in musl 1.2.2 we should be able to drop it when
we upgrade to 1.2.2 or later.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

With openharmony-linux-user.patch, we were modifying sys/socket.h header so
that struct sockaddr_storage was coming from linux/socket.h header instead of
being defined directly.

But upstream linux/socket.h does not do that.  It seems like some kind of
Android convention, that have been applied to kernel headers in OpenHarmony,
and as we now are using kernel headers from Oniro, we don't have that.

As part of the reason for using third party from Oniro, we really do want to
use upstream kernel headers, so we need to drop this change.

Note that this difference can be seen as an API change compared to
OpenHarmony.  Code that would be relying on linux/socket.h defining
struct sockaddr_storage will not work without changes.  But the sensible API
is to include sys/socket.h, and in that case, compatibility is preserved.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>

This reverts to upstream version 1.2.0 plus patches extracted from
//third_party/musl component in OpenHarmony-v3.0-LTS code base.

Signed-off-by: Esben Haabendal <esben.haabendal@huawei.com>