Regarding libomp · termux/termux-packages#6145

(10 评论) (0 反应) (0 负责人)Shell (16,216 star) (4,089 fork)batch import

discussionenhancementhelp wanted

描述

https://github.com/android/ndk/blob/master/Changelogs/Changelog-r21.md

Apparently since NDK r21, it ships a shared variant of libomp. This is more or less proven to be true as per #6140.

I think we should probably ship it like we do for libc++ anyway, especially when we never shipped a libomp.so in our clang. And it seems to me that we should probably replace our libomp.a and omp.h with the ones from the NDK as well.

I'm not entirely sure if any of them could be problematic to our clang though. So I also wonder if we should just do -static-openmp in our packages and leave our clang as-is.

And I guess it's not impossible / entirely unacceptable to ship only the shared variant from the NDK as runtime library for our packages, and configure/patch our clang to always set -static-openmp. Whether it's a better approach than the above two is in doubt though.

What do you think?

贡献者指南

技术栈: ccpp
领域: infrastructurebuild system
议题类型: research
难度: 4
预计时间: 1-2 days
活动状态: stale
清晰度: mostly clear
前置要求: Understanding of Termux packaging systemFamiliarity with NDK and libompKnowledge of clang compiler flagsExperience with shared libraries
新手友好度: 20
研究方向: Investigate the NDK r21+ shared libomp.so and its compatibility with Termux's clang. Examine the NDK Changelog and the linked issue #6140 for context. Test if dynamic linking of libomp works with existing Termux clang builds. Compare the two approaches: shipping only the shared variant from NDK vs configuring clang to use static openmp. Document the findings and gather maintainer feedback on the preferred solution.