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

Jorn Vernee jvernee at openjdk.org
Mon Jul 10 22:52:12 UTC 2023


On Mon, 10 Jul 2023 22:27:12 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 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.

I'm not suggesting that the application code should be changed. I'm suggesting that a broader solution should be found that avoids this issue in the future, rather than having to patch hotspot again for the next application that comes along and defines a symbol that conflicts. That's what I mean by "principled". I.e. we should be able to explain how to avoid symbol conflicts when statically linking applications against hotspot. I don't think that telling users that, if they have a symbol conflict: "just file a bug report and we will patch hotspot to use a different symbol" is good enough.

For instance, we could put all of hotspot into a `HotSpot` namespace, and then document this name space name and require that applications that want to statically link against hotspot don't use the `HotSpot` name space. That would also avoid having to fix up uses of these symbols inside hotspot itself, since things in the same namespace can refer to each other already, without needing a qualifier.

> 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:
> 
> [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166157315) [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166209365) [#13451 (comment)](https://github.com/openjdk/jdk/pull/13451#discussion_r1166283513)

Thanks for the pointers. So it sounds like limiting the symbols 'exported' by a static library is not really possible.

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

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


More information about the graal-dev mailing list