RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v2]

Andrew Haley aph at openjdk.org
Wed Jan 24 09:30:48 UTC 2024


On Tue, 11 Jul 2023 22:57:09 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > I found a way to hide the unwanted symbols in libjvm.a. This requires `ld --relocatable` and `objcopy --keep-global-symbols=...`. See the prototype here:
> > 
> > * https://github.com/iklam/tools/tree/main/misc/staticlib
> > 
> > So potentially we can do this completely in the makefiles, without adding namespaces to HotSpot.
> 
> Yeah, `objcopy` can be used to localize symbols. One of my colleague @cjmoon1 implemented symbol localizing for `libfreetype.a` and `libharfbuzz.a` for static linking issue. In some cases, user might want to link with a different version of the harfbuzz library than the version linked with the JDK code. Then multiple versions of the libraries could be linked together into the executable. That was a solution suggested by C++ experts and it worked. Doing partial linking that produces a single `.o` file simplifies the work of `objcopy`. This is not a very portable solution though.

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/14808#issuecomment-1907728552


More information about the graal-dev mailing list