我碰到过类似的Arch Linux+Gradle+Java9+兼容性问题，结合你要发布到Arch用户仓库的需求，给你几个可行的解决方案：

1. 修复系统级javah符号链接（Arch环境专属） #

Java 9+已经把javah的功能整合到javac -h中，Arch Linux的/usr/bin/javah通常是个遗留的无效符号链接。你可以重新创建它指向javac，让Gradle能正常解析：

sudo ln -sf /usr/bin/javac /usr/bin/javah

如果是打包到Arch仓库，你可以把这个命令加到PKGBUILD的package()函数里，确保安装时自动修复链接，不会影响用户的系统环境。

2. 修改Gradle脚本，让copyRunScript任务跳过无效符号链接 #

既然报错出在copyRunScript任务，直接调整这个任务的配置即可：

方案A：排除javah路径 #

如果你的脚本不需要复制javah，直接在任务里排除它：

tasks.named('copyRunScript') {
    exclude '/usr/bin/javah'
}

方案B：禁用符号链接跟随 #

让Gradle在复制时不尝试解析符号链接，避免触发错误：

tasks.named('copyRunScript') {
    followSymlinks = false
    // 保留你原有的复制配置
}

3. 升级Gradle版本（推荐长期方案） #

Gradle 5.4.1是比较旧的版本，对Java 9+的兼容性支持不够完善。升级到6.x或7.x系列的Gradle（这些版本对Java 9+的适配更好），大概率能自动处理这种符号链接的问题。
如果是发布到Arch仓库，只需要在PKGBUILD里指定升级后的Gradle版本即可，不会影响用户使用。

4. 替换代码中javah的调用逻辑 #

如果你的程序确实需要生成JNI头文件，把代码里调用javah的地方全部替换成javac -h——这是Java 9+官方推荐的替代方式，从根本上避免依赖javah这个已废弃的工具。

补充提示：Arch Linux的Java包结构和其他发行版差异较大，Java 9+不再提供单独的javah二进制文件，这是问题的核心根源。上面的方案都能适配Arch用户仓库的发布需求，不会引入额外的兼容性问题。

内容的提问来源于stack exchange，提问作者user122109091234