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. > > I think you should be able to use ld and objcopy to merge the .o files and > > hide all of the symbols you don't want to export. > > We also discussed about `objcopy` in [#14808 > (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631597197) > and [#14808 > (comment)](https://github.com/openjdk/jdk/pull/14808#issuecomment-1631611220). > My main concern was the portability of `objcopy` approach. I replied: OK, but it is the right thing to do on Linux. If some other operating systems don't provide useful tools, that's on them. I haven't checked, but I strongly suspect that LLVM can do it too, so all that remains is Windows, and maybe they can't have static linking (or maybe they have to use something like this PR) until the right tooling is provided. If Windows really can't do it, that's no reason to burden systems that can. Namespaces are not a low-cost solution for developers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1907730900
