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

[Jiangli Zhou]

On Thu, 13 Apr 2023 23:07:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

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

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