RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking

David Holmes dholmes at openjdk.org
Thu Jan 18 07:30:14 UTC 2024


On Wed, 17 Jan 2024 00:14:58 GMT, Jiangli Zhou <jiangli at 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


More information about the serviceability-dev mailing list