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. > Linking failures were observed when statically linking the launcher > executable with hotspot and user native code together: So the problem is that the user native code defines Thread as well - right? So this could keep happening for name after name depending on what native code is being linked. I second what @theRealAph said! This is really ugly. The way disparate libraries just get munged into a single namespace with static linking just seems wrong to me. At a minimum this hack should only be used when doing static linking as Coleen suggested. But I'd much prefer a solution that came from the tools doing the linking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1897940456
