On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jian...@openjdk.org> wrote:
> Please review this PR with a simple solution for resolving duplicate `Thread` > symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there > was an alternative suggestion to redefine the symbol at build time, such as > using`-DThread=HotSpotThread`. That would not address issues when symbol were > references as string literals. https://github.com/openjdk/jdk/pull/14808 also > discussed using namespace for hotspot code, which can have multiple > benefits/motivations. We could explore further using namespace with more > consensus on that approach. > > Contributed by Chuck Rasbold and @jianglizhou. We (@AlanBateman, @cushon, @magicus, @jerboaa, @pron, @jianglizhou) discussed this topic via zoom as part of a regular static/hermetic Java discussions. The outcome favors the partial-linking/objcopy to localize symbols for hotspot. Here is a summary: - A general solution is preferred compared to resolving symbol issues case by case. - We can address this for unix-like platforms with toolings supporting partial-linking/objcopy for now. @magicus will provide additional information on supported gcc versions and considerations for Windows support. - There is also a preference to localize symbols automatically without editing the symbol list manually. In our prototype for handling freetype symbols (as mentioned in https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220), @cjmoon1 looked into using `nm` to generate symbol list and feed that into `objcopy`. That might be do-able for hotspot symbols. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1917753387
