OpenJ9项目中Semeru构建错误分析与解决

背景介绍

在OpenJ9项目的Semeru分支构建过程中，开发团队遇到了一个编译错误，该错误出现在DHKey.c文件的Java_com_ibm_crypto_plus_provider_ock_NativeInterface_DHKEY_1createKey函数中。错误信息表明在调用JCC_d2i_Key函数时，传递了不兼容的指针类型参数。

错误详情分析

编译错误的具体表现为：

error: passing argument 4 of 'JCC_d2i_Key' from incompatible pointer type

编译器明确指出，函数期望接收的是unsigned char类型的参数，但实际传递的是const unsigned char类型。

这种类型不匹配在C语言中是一个常见的编译错误，特别是在处理加密相关函数时，因为加密API通常对数据的可变性有严格要求。在这个案例中，函数原型定义要求非const指针，而调用方传递了const指针，这在C语言中是不安全的隐式转换，因此编译器报错。

根本原因

经过团队分析，这个问题源于OpenJCEPlus项目最近的一次更新。在这次更新中，团队为9月发布的版本更新了ICC动态链接库(ICC dll)，但相关变更尚未完全同步到所有构建环节中。

特别值得注意的是，Semeru构建系统不使用常规的tooling仓库，而是依赖temurin-build项目中的prepareWorkspace.sh脚本。这个脚本需要相应更新以匹配OpenJCEPlus的变更，否则就会导致上述类型不匹配的编译错误。

解决方案

开发团队采取了以下解决措施：

1. 更新temurin-build项目中的prepareWorkspace.sh脚本，确保Semeru构建流程与最新的OpenJCEPlus变更保持一致。

2. 对于不同的构建场景采用不同的分支策略：

   • 主线开发(head stream)使用semeru-java11分支
   • 正式发布版本使用semeru-java-11.0.28等特定版本分支

3. 同步更新0.53分支，使其使用新版本的OpenJCEPlus和相应ICC级别。

经验总结

这个案例展示了在大型开源项目中，组件间依赖管理的重要性。特别是当涉及加密相关功能时，类型系统的严格性会暴露潜在的接口不一致问题。开发团队通过以下方式有效解决了问题：

1. 准确识别构建系统与源代码之间的版本不匹配
2. 针对不同构建场景采用适当的分支策略
3. 确保所有相关组件同步更新

这种系统性的解决方案不仅修复了当前的编译错误，也为未来类似的跨组件协调问题提供了参考模式。