h-没有这样的文件或目录-正确设置JAVA_HOME环境变量

我目前正在尝试在Linux的Windows子系统中使用jni.h

每当我尝试设置/运行它时，都会收到此错误消息。

我只是想知道如何成功地正确设置Java_HOME变量，以便它能够找到JNI.h

任何帮助都是非常需要的，因为我真的不知道从哪里开始，因为我还不熟悉设置路径

到目前为止，我的两个build.gradle文件包括：

这是我的c子项目中的build.gradle

plugins {
    // We're actually using C++, but we can essentially pretend that it's C.
    // The cpp-library plugin compiles our C/C++ code and generates a library file.
    id 'cpp-library'
}

    tasks.withType(CppCompile).configureEach 
    {
    
    // The actual 'jni.h' file lives in the 'include' directory, but there are 
    also a series of 
    // other, platform-specific header files in 'include/linux' and/or 
    'include/win32'. Your actual
    // JDK may only have one of these platform-specific directories.
    
    includes "$System.env.JAVA_HOME/include"
    includes "$System.env.JAVA_HOME/include/linux"
    includes "$System.env.JAVA_HOME/include/win32"
    includes "$System.env.JAVA_HOME/include/win64"
}

library {
    // Define the library's name. (The file produced will be 'lib<baseName>.so' on Linux or 
    // '<baseName>.dll' on Windows.)
    baseName = 'example_c_library'

    // Create a 'shared' library only (not a 'static' library).
    linkage = [Linkage.SHARED]
    
    // What is the target platform?
    targetMachines = [
        machines.linux.x86_64,
        machines.windows.x86_64,
        machines.macOS.x86_64
    ]
}

plugins {
    id 'java'
    id 'application'
}

// We need Gradle to finish configuring the other sub-project first, because we need to
// refer to two of its tasks below.
evaluationDependsOn ':c_library'

def libTasks = project(':c_library').tasks
def debugLibTask = libTasks.matching{ it.name.startsWith('linkDebug') }.first()
def releaseLibTask = libTasks.matching{ it.name.startsWith('linkRelease') }.first()

dependencies {
    // Make this subproject ('java_app') depend on the file produced by the linking task in the 
    // other subproject.
    runtimeOnly files(releaseLibTask.linkedFile)
    
    // This declaration is more convoluted than you might expect. We can't simply depend on the 
    // other subproject as a whole, because that makes the Java plugin complain that it isn't 
    // another Java project. There's no automated logic for tying a C library into a Java 
    // application.
    
    // Instead, this dependency simply causes our C library file to be included as part of the Java 
    // application's distributable .zip file. We then have to do some setting up, in 'run{}' and 
    // 'startScripts{}', to ensure that Java will be able to load the library.
}

application {
    mainClassName = 'org.example.ExampleJavaApp'
}

run {
    // Make 'gradlew run' set the library path correctly. There is a Java "system property" for 
    // this, which needs to be set to the *directory* containing the shared library.
    
    // We first depend on the 'linkDebug' task that creates the debug version of the library, to
    // ensure that task runs before the 'run' task. Then we make a few more calls to extract the 
    // actual directory, and set the library path.
    
    // Debug vs release? Gradle builds two versions of our C code with different compiler options,
    // one intended for debugging (which is what we're theoretically doing when we execute 'run'),
    // and one for release (which is what the final .zip file is for).
    
    dependsOn debugLibTask
    systemProperty 'java.library.path', debugLibTask.linkedFile.get().asFile.parentFile
}

startScripts {
    // Make the start-up scripts (both UNIX and Windows) set the library path correctly, so that 
    // our application is properly distributable.
    
    // When our application is distributed, the native library will live inside the same 'lib/' 
    // directory that contains the rest of our code. So the library path needs to be the 'lib/' 
    // directory. However, we can't hardcode the location of this directory, because we can't know 
    // in advance where the user has installed the application. Instead, we have to get the 
    // start-up script (both the UNIX and Windows version of it) to figure it out.

    // How we do *that* is a bit hacky though. We first tell the script generator how to set the 
    // path, but at the "last minute" we go in and tweak the result, because the actual path 
    // depends on a variable in the script that we can't access in the first instance.
    
    defaultJvmOpts = ['-Djava.library.path=APP_HOME_PLACEHOLDER/lib']
    
    doLast {
        unixScript.text = unixScript.text.replace('APP_HOME_PLACEHOLDER', '$APP_HOME')
        windowsScript.text = windowsScript.text.replace('APP_HOME_PLACEHOLDER', '%APP_HOME%')
    }
}

---

到目前为止，我已经按照讲师的建议尝试了导出LD_LIBRARY_PATH=build/libs/mynativellibrary/shareddo这能回答你的问题吗？您的构建系统是什么样子的？它如何配置JNI头的路径？应该是

-I

标志。设置LD_LIBRARY_PATH仅用于运行时库查找，您还未处于该阶段。@NathanMills不适用于代码块。@Botje刚刚添加了我的build.gradle，我想这正是您的意思