RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries

[Jaikiran Pai]

On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> - Make functions 'static' when feasible:
>   - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
>   - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
>   - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c.
>   - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c.
>   - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static.
>   - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static.
> 
> - Rename functions by following the existing naming usages in different libraries code:
>   - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss.
>   - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11.
>   - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11.
>   - Rename throwIOException() to p11ThrowIOException() in libj2pks11.
>   - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw<exception> functions.
> 
> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used.
> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c.

Hello Jiangli, I have no experience in C language or the symbol linking that's involved in this PR, but given similar PRs that have been merged recently, is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? I realize that you have been working on JDK-8303796 which proposes to build statically linked JDK image. Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in?

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

PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1512486343