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

[Jiangli Zhou]

On Thu, 13 Apr 2023 20:04:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36:
>> 
>>> 34: const JmmInterface* jmm_interface_management_ext = NULL;
>>> 35: static JavaVM* jvm = NULL;
>>> 36: jint jmm_version_management_ext = 0;
>> 
>> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ??
>
>> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ??
> 
> Good question.
> 
> We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base.
> 
> Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution.
> 
> The direct renaming in this case seems to be more strait forward. Any thoughts?

Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ...

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

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