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

[Jiangli Zhou]

On Mon, 10 Jul 2023 21:19:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8311661
>>  - Move  '} // namespace JavaClassFile' to after '#endif //INCLUDE_CDS_JAVA_HEAP'.
>>  - 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking
>
> The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This patch seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot.
> 
> For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead?

@JornVernee thanks for looking into this.

> The JBS issue says: "That avoids having to fix the application or libraries code, which may not be practical." but I'm not sure how changing hotspot every time an application defines a conflicting symbol is more practical? This patch seems like a band-aid to make one particular application work. I think a more principled solution is needed that avoids symbol conflicts going forward, if we are serious about supporting static linking of hotspot.

Changing the application or libraries code is not practical in this case as we don't have the full control of what applications or libraries may be linked with. In some cases, developers may not have access to the actual code or required insights to resolve the linkage failures. Fixing the hotspot code using namespace in this case resolves the issue from the source at once, which makes this as a more principled approach.

> 
> For instance, the symbols that _should_ be exported from hotspot are found in several files in make/data/hotspot-symbols. Is it possible to limit the symbols exported/visible in the static library to those symbols instead?

The linking failure involved with duplicate symbol issue concerns internal linkage vs. global linkage, which is different from symbol exporting, IIUC. When duplicating symbol with global linkages from different compilation units linked together, it causes the linking failure. On the other hand, exporting a symbol putting the symbol in the export table, so the symbol can be dynamically looked up. Please see some detailed discussions in:

https://github.com/openjdk/jdk/pull/13451#discussion_r1166157315
https://github.com/openjdk/jdk/pull/13451#discussion_r1166209365
https://github.com/openjdk/jdk/pull/13451#discussion_r1166283513

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1629814917