调用C++；来自Java，但Java加载了错误的Glibc版本 我试图从java端调用C++库，并编写了必要的JNI代码。但是，当我的java代码试图通过 St.RooLabys加载C++库时，它抱怨以下错误： Exception in thread "main" java.lang.UnsatisfiedLinkError: libmylib.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by libmylib.so) Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/local/gcc-4.8.1-glibc2.17/lib/libc-2.17.so: __vdso_time: invalid mode for dlopen(): Invalid argument

后来我发现这是因为我的系统上有两个不同的GLIBC版本，默认版本是旧版本，而

libmylib。因此需要从新的GLIBC构建
。因此，java链接到错误的GLIBC

我试过以下方法，但不起作用

第一个是尝试通过java代码中的
System.load
手动加载正确的库。具体来说，我在加载库之前添加了以下代码：

static {
  System.load("/usr/local/gcc-4.8.1-glibc-2.17/lib/libc.so.6");
  System.load("/usr/local/gcc-4.8.1-glibc-2.17/lib/libstdc++.so.6.0.18");      
  System.loadLibrary(mylib);
}

还添加了libc.so.6，因为libstdc++依赖于它（否则java将加载错误的libc并报告另一个错误）

Exception in thread "main" java.lang.UnsatisfiedLinkError: libmylib.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by libmylib.so)

Exception in thread "main" java.lang.UnsatisfiedLinkError:
  /usr/local/gcc-4.8.1-glibc2.17/lib/libc-2.17.so:
      __vdso_time: invalid mode for dlopen(): Invalid argument

这个错误是由于混合了两个版本的GLIBC造成的，如中所述。
这个问题的解决方案是用C++编写程序，代码< > WL，动态链接器< /> >设置正确（也描述）。但是，我不知道如何在java中实现。
我试图将
LD_LIBRARY_PATH
设置为较新版本，但情况完全相同：（

我能知道如何使java链接到正确的库吗

（注：由于我的机器中的许多其他应用程序依赖于当前默认的glibc，因此最好使用没有make-install更新版本glibc的解决方案）

几天来，我一直在寻找和尝试解决问题的方法，但没有一个成功：(

Stackoverflow，你是我唯一的希望：~.
尝试使用LD\u PRELOAD=new\u c\u library.so java-javastuff

System.load（“/usr/local/gcc-4.8.1-glibc-2.17/lib/libc.so.6”）；

正如我所解释的，这不可能奏效

当您到达上述语句时，系统
libc.so.6
已经加载（在进程启动时），并且您绝对不能将两个版本的
libc.so.6
加载到同一进程中。
我试图将LD\u LIBRARY\u PATH设置为较新版本你是怎么做到的？不确定我是否做对了。我尝试了通过
将LD_LIBRARY\u PATH=PATH\u导出到新glib
，也尝试了
java-Djava.LIBRARY.PATH=PATH\u导出到新glib
，但都抱怨相同的
\u vdso\u时间：dlopen（）的模式无效：无效参数
错误。我猜错误消息意味着您的
LD_LIBRARY_PATH
设置有效。动态链接器的路径是在可执行文件中硬编码的，这就是问题所在。在您的情况下，我猜可执行文件是
java
本身。当
java
尝试加载动态库时，它可能会使用
dlopen（）
，它将使用与使用的
java
相同的动态链接器。仍然会遇到相同的问题：~~
java:加载共享库时出错：\uu vdso\u time:dlopen（）的模式无效：无效参数
。我做错什么了吗？我希望人们不要再建议
libc.so.6的
LD\u PRELOAD
。只需想想哪个代码解释
LD\u PRELOAD
（提示：该代码在libc中！）@EmployedRussian:ld-linux.so不是静态构建的吗？它是动态链接器，不能要求自己运行。因此，它不应该引入libc符号。“ld-linux.so不是静态的吗？”--它很复杂。不，它不是完全静态的，正如运行
readlink-dld-linux.so.2
可以看到的那样。它也会拉取
libc.so.6
符号，这可以通过在GDB下运行二进制文件、设置
catch syscall mmap64
并查看堆栈来观察到，前几个调用将由
ld-linux
执行直接，但随后的调用将通过libc.so.6
@EmployedRussian进行：可能它已经改变了，或者选项不同了，但是当我在2008年进行大量Gentoo构建时，我几乎完全确定ld-linux.so是静态的，没有加载任何内容。因为预加载对我来说是有效的。