'StringTable::StringTable' appears to be a more commonly used symbol. When statically linking JDK and hotspot native libraries with application's native and dependencies, we observed symbol issues like the following when the symbol is also defined by application native or other native libraries.
```
ld: error: duplicate symbol: StringTable::StringTable()
>>> defined at stringTable.cpp:198 (/.../src/hotspot/share/classfile/stringTable.cpp:198)
>>> libjvm_relocatable.o:(StringTable::StringTable()) in archive .../java/jdk/jdk11-k8/lib_static/libjvm.a
>>> defined at ...
```
One solution is to move hotspot StringTable to an unique namespace, such as 'JavaClassFile'. That avoids having to fix the application or libraries code, which may not be practical. We've tested the namespace solution in prototype, which worked out well.
```
ld: error: duplicate symbol: StringTable::StringTable()
>>> defined at stringTable.cpp:198 (/.../src/hotspot/share/classfile/stringTable.cpp:198)
>>> libjvm_relocatable.o:(StringTable::StringTable()) in archive .../java/jdk/jdk11-k8/lib_static/libjvm.a
>>> defined at ...
```
One solution is to move hotspot StringTable to an unique namespace, such as 'JavaClassFile'. That avoids having to fix the application or libraries code, which may not be practical. We've tested the namespace solution in prototype, which worked out well.
- relates to
-
JDK-8303796 Optionally build fully statically linked JDK image
- Open
-
JDK-8311846 Resolve duplicate 'Thread' related symbols with JDK static linking
- Open
- links to
-
Review openjdk/jdk/14808