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