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

[Jiangli Zhou]

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.

Hi Jaikiran,

Thanks for looking into this.

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

The symbol issues are reported as linker errors when statically linking the executable with JDK native libraries and libjvm. I just created a branch with the preliminary makefile changes for optionally statically linking JDK, which can be used to demonstrate/identify the issues:

  https://github.com/jianglizhou/jdk/pull/new/JDK-8303796

The branch is based on our prototype on JDK 11, but mostly reworked. It re-uses the existing JDK make infrastructure based on the feedback from Severin Gehwolf in https://bugs.openjdk.org/browse/JDK-8303796. Still need to clean up the makefile changes before making it ready for review. Early feedback/input is also welcomed.

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

Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK.

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

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