RFR: 8305935: Resolve multiple definition of 'jmm_<interface|version>' when statically linking with JDK native libraries

[Jiangli Zhou]

On Fri, 14 Apr 2023 00:34:14 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> The direct renaming in this case seems to be more strait forward.
>> 
>> If we were to do this then we should have a naming convention of some kind e.g. `<lib-name>_<var-name>` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem.
>
>> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data?
> 
> If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything.
> 
> objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object
> SYMBOL TABLE:
> 0000000000000000 l    df *ABS*	0000000000000000 management_ext.c
> ...
> 0000000000000000 g     F .text	0000000000000068 JNI_OnLoad
> 0000000000000008 g     O .bss	0000000000000008 .hidden jvm
> 0000000000000000         *UND*	0000000000000000 JVM_GetManagement
> 0000000000000010 g     O .bss	0000000000000008 .hidden jmm_interface
> 0000000000000000 g     O .bss	0000000000000004 .hidden jmm_version

> If we were to do this then we should have a naming convention of some kind e.g. `<lib-name>_<var-name>` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem.

Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166165671