feat: add openharmony header for libc

[richerfu]

No description provided.

[richerfu]

Hi @andrewrk
This PR enables us to use zig cc as a fundamental feature in building the OpenHarmony-related SDK. As OpenHarmony currently lacks robust CI/CD tools or capabilities, I'm unable to provide relevant CI updates. However, I believe this PR is mostly free of significant issues at this point. Could you possibly take a moment to review it? Thanks

[The-King-of-Toasters]

Can you document how other contributors can setup their own OHOS environments for testing your changes? From my limited research it seems you to use DevEco studio to get started, but I can't seem to find a download link for it.

[richerfu]

1. The OpenHarmony NDK download link can be found in openharmony ci ecosystem.

2. For the release version, we can use this directly. Rust's ci also uses this package.

3. But there is no good way to run some something.
   run the Ohos app in the emulator in CI. This is blocked on either the HarmonyOS NEXT emulator becoming publicly available, or figuring out how to run pure OpenHarmony on qemu
   and you can get related issue with servo Tracking issue: OpenHarmony port servo/servo#32644

4. For DecEco Studio, you can download it https://docs.openharmony.cn/pages/v4.1/zh-cn/release-notes/OpenHarmony-v4.1-release.md#%E9%85%8D%E5%A5%97%E5%85%B3%E7%B3%BB.

   note: support for i18n is not very good :(

[alexrp]

• I think you should submit the emutls.zig and c.zig changes in a separate PR.
• It would be good to have a link to where these C headers are sourced from, and which exact version or commit hash.
• It's unclear why the lib/libc/include/*-linux-ohos/asm directories are needed. Linux headers are already available under lib/libc/include/*-linux-any.
• I think the headers should be split into generic (lib/libc/include/generic-ohos) and target-specific (lib/libc/include/*-linux-ohos) as is done for regular musl.
  • Perhaps you could copy tools/process_headers.zig, strip it down to just the musl stuff, and specialize it for OpenHarmony's musl fork. If we're going to have these headers in-tree, it would be great to have similar tooling that we do for regular musl.

Edit: That said, given #20875, you might still want to wait on Andrew's sign-off on this before doing the above work.

[richerfu]

Hi @alexrp thanks for your advice. For OpenHarmony support, I'm planning to divide it into two PRs, one for adding header files and the other for managing zig cc logic. I've adjusted the logic in this PR based on your suggestions. However, there are still two points that need clarification:

1. Should we incorporate system capability header files into generic-ohos?
2. We may need to hold off on merging until the issue you brought up is resolved.

[alexrp]

Should we incorporate system capability header files into generic-ohos?

Can you clarify what you mean by this?

[richerfu]

Should we incorporate system capability header files into generic-ohos?

Can you clarify what you mean by this?

Take generic-ohos/arkui/native_dialog.h for example, it's a header file used for rendering UI on OpenHarmony devices and it relies on a dynamic link library libace_ndk.z.so that's built into the system.

If we were to include it in libc, we might face two issues:

1. Should we also add the source code or dynamic link library that the corresponding header file implements (akin to libc.so)?
2. The size of the zig repository might increase significantly due to the volume of similar files, header files and dynamic link libraries.

[alexrp]

Ah, I see what you mean. No, we only ship headers for libc and any constituent libraries like libpthread, libdl, etc. The "generic" here should be interpreted to mean "generic across architectures".

[richerfu]

Ah, I see what you mean. No, we only ship headers for libc and any constituent libraries like libpthread, libdl, etc. The "generic" here should be interpreted to mean "generic across architectures".

OK, i will remove it. Thanks for your reply :)

[andrewrk]

draft status, no updates in 30+ days