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

[David Holmes]

On Fri, 14 Apr 2023 02:09:47 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> 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?
>
> David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. 
> 
> It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach.

Thanks for the pointer to stackoverflow - that made things a lot clearer. 

The symbol localization using `objcopy` seems to achieve what we desire but has the same drawback as renaming, that you need to know the symbols will clash to localize them. And it is also not ideal that changing the code may also need a change to the build file. :(

With that in mind a simple renaming seems the least worst option for fixing this.

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

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