/usr/lib/libstdc++.so.6:版本“GLIBCXX_3.4.15”未找到
如何在 Ubuntu 中获取 GLIBCXX_3.4.15?我无法运行我正在编译的一些程序。
当我这样做时:
strings /usr/lib/libstdc++.so.6 | grep GLIBC
我得到:
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.4
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
感谢您的帮助!
How can I get GLIBCXX_3.4.15 in Ubuntu? I can't run some programs that I'm compiling.
When I do:
strings /usr/lib/libstdc++.so.6 | grep GLIBC
I get:
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.4
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
Thanks for any help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(19)
我正在从源代码编译 gcc 4.6,显然
没有抓住这个。我四处寻找,发现
我将其复制到 /usr/lib 并重定向 libstdc++.so.6 以指向新的,现在一切正常。
I'm compiling gcc 4.6 from source, and apparently
didn't catch this one. I dug around and found
I copied it in to /usr/lib and redirected libstdc++.so.6 to point to the new one, and now everything works.
过去,我一直通过在链接我的可执行文件时简单地将 libstdc++ 与发送到 g++ 的参数静态链接来避免此问题:
如果静态链接库是一个选项,这可能是最快的解决方法。
I have been avoiding this issue in the past by simply linking libstdc++ statically with this parameter sent to g++ when linking my executable:
If linking in the library statically is an option this is probably the quickest work-around.
我试图让 clang 工作(这也需要 6.0.15),在四处查看时我发现它安装在
/usr/local/lib/libstdc++.so.6.0.15
处。当我安装石墨(一个实验性的 gcc 版本)时它就安装在那里。如果您需要访问该位置的库,则需要将 LD_LIBRARY_PATH 定义为:
export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/local/ lib64:/usr/lib64
完成此操作后,我能够让 clang 工作。希望这对某人有帮助。
I was trying to get clang to work (which also requires 6.0.15), and while poking around I found it was installed at
/usr/local/lib/libstdc++.so.6.0.15
. It installed there when I installed graphite (an experimental gcc version).If you need access to libraries at that location, then you’ll need to define
LD_LIBRARY_PATH
as:export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/local/lib64:/usr/lib64
I was able to get clang to work after doing this. Hope that is helpful to someone.
当我尝试使用 matlab eng 从 c 代码调用 m 函数时遇到这个问题。
这是使用命令
mex -f .. ..
我的解决方案:
我发现它包含 3.4.15,
所以我的系统有最新的库。
问题来自于matlab本身,它从
{MATLAB}/bin
调用自己的libstdc++.so.6,所以只需将其替换为更新的系统lib即可。
I encounter this problem when trying to use matlab eng to call m functions from c code.
which occurs with command
mex -f .. ..
My solution:
I found it includes 3.4.15
so my system has the newest libs.
the problem comes from matlab itself, it calls its own libstdc++.so.6 from
{MATLAB}/bin
so, just replace it with the updated system lib.
有时您无法控制目标机器(例如您的库需要在锁定的企业系统上运行)。在这种情况下,您需要使用与其 GLIBCXX 版本相对应的 GCC 版本重新编译代码。
在这种情况下,您可以执行以下操作:
strings /usr/lib/libstdc++.so.6 | grep GLIBC
...假设版本是3.4.19
。[4.8.3, 4.9.0)
。Sometimes you don't control the target machine (e.g. your library needs to run on a locked-down enterprise system). In such a case you will need to recompile your code using the version of GCC that corresponds to their GLIBCXX version.
In that case, you can do the following:
strings /usr/lib/libstdc++.so.6 | grep GLIBC
... Say the version is3.4.19
.[4.8.3, 4.9.0)
.我刚刚在构建 LLVM 3.7 版本时遇到了类似的问题。
首先检查您的系统上是否安装了所需的库:
然后将找到的位置添加到 $LD_LIBRARY_PATH 环境变量中。
I have just faced with similar issue building LLVM 3.7 version.
first check whether you have installed the required library on your system:
Then add the found location to your $LD_LIBRARY_PATH environment variable.
我遇到了同样的错误。这就是它对我来说的工作方式:
工作完美!
I got same error. This is how it worked for me:
Worked perfectly!
对于这个错误,我从其他服务器复制了最新的libstdc++.so.6.0.17,并删除了软链接并重新创建了它。
1. 将 libstdc++.so.6.0.15 或最新版本从其他服务器复制到受影响的系统。
就我而言,SUSE linux 11 SP3 是最新的。
2. rm libstdc++.so.6
3. ln -s libstdc++.so.6.0.17 libstdc++.so.6(在/usr/lib64目录下)。
nJoy
For this error, I copied the latest libstdc++.so.6.0.17 from other server, and removed the soft link and recreated it.
1. Copy the the libstdc++.so.6.0.15 or latest from other server to the affected system.
In my case SUSE linux 11 SP3 had latest.
2. rm libstdc++.so.6
3. ln -s libstdc++.so.6.0.17 libstdc++.so.6 (under /usr/lib64 directory).
nJoy
GLIBCXX_3.4.14 的错误
您需要安装更新版本的 GCC。
http://pkgs.org/download/libstdc++.so.6
转到:
http://geeksterminal.com/how-to-install-glib- glibc/1392/
并按照说明进行操作。
Bug with GLIBCXX_3.4.14
You need to install a newer version of GCC.
http://pkgs.org/download/libstdc++.so.6
goto:
http://geeksterminal.com/how-to-install-glib-glibc/1392/
and follow instructions.
我遇到了同样的问题,因为我将用户从自己更改为其他人:
su
由于某种原因,在正常编译后我无法执行它(相同的错误消息)。直接 ssh 到其他用户帐户即可。
I had the same problem because I changed the user from myself to someone else:
su
For some reason, after did the normal compiling I was not able to execute it (the same error message). Directly ssh to the other user account works.
我安装了多个版本的 gcc 编译器,并且需要使用比默认安装更新的版本。由于我不是 Linux 系统的系统管理员,因此我不能只更改 /usr/lib 或上面的许多其他建议。我遇到了这个问题,并最终追踪到将我的路径设置为 32 位库目录而不是 64 位库 (lib64) 目录。由于32位目录下的库不兼容,系统默认使用已经过时的旧版本。
对我引用的路径使用 -L 会发出有关“搜索 -lstdc++ 时跳过不兼容的 libstdc++.so”的警告。这是帮助我最终解决问题的提示。
I had multiple versions of the gcc compiler installed and needed to use a more recent version than the default installation. Since I am not a system administrator for our Linux systems, I cannot just change /usr/lib or many of the other suggestions above. I was encountering this problem and eventually tracked it down to setting my path to the 32-bit library directory instead of the 64-bit library (lib64) directory. Since the libraries in the 32-bit directory were incompatible, the system defaulted to the older version which was out of date.
Using -L to the path I was referencing gave warnings about "skipping incompatible libstdc++.so when searching for -lstdc++". This was the hint that helped me finally resolve the problem.
gcc版本4.8.1,错误看起来像:
我在编译 gcc 4.8.1 的地方找到了 libstdc++.so.6.0.18
然后我确实喜欢
解决这个问题。
gcc version 4.8.1, the error seems like:
I found the libstdc++.so.6.0.18 at the place where I complied gcc 4.8.1
Then I do like this
problem solved.
我已经从 RPM 中提取了它们(libstdc++ 的 RPM) 然后:
设置系统在当前目录中搜索库。然后就执行了我的程序。但就我而言,我收到了我需要的单个可执行文件,这不是系统范围的更改。
I've extracted them from an RPM (RPM for libstdc++) and then:
To set the system to search for the libraries on the current directory. Then just executed my program. But in my case I've received a single executable that I needed, it wasn't a system wide change.
就我而言,LD_LIBRARY_PATH 在 /usr/local/lib64 之前先有 /usr/lib64。 (我正在构建 llvm 3.9)。
我安装的用于编译 llvm 3.9 的新 gcc 编译器在 /usr/local/lib64 下有使用较新 GLIBCXX 库的库,因此我修复了 LD_LIBRARY_PATH 以便链接器首先查看 /usr/local/lib64。
这解决了这个问题。
In my case LD_LIBRARY_PATH had /usr/lib64 first before /usr/local/lib64. (I was builing llvm 3.9).
The new gcc compiler that I installed to compile llvm 3.9 had libraries using newer GLIBCXX libraries under /usr/local/lib64 So I fixed LD_LIBRARY_PATH for the linker to see /usr/local/lib64 first.
That solved this problem.
我只是在构建时使用了 -static-libstdc++ 。
有了这个,我可以运行 a.out
I just used -static-libstdc++ while building.
w/ that, I can run the a.out
我遇到了类似的问题,我通过静态链接
libstdc++
到我正在编译的程序中解决了这个问题,如下所示:而不是通常的
这个解决方案可能会出现与加载有关的问题在运行时共享库,但我还没有深入研究这个问题来发表评论。
I've had a similar issue, and I've resolved it by statically linking
libstdc++
into the program I was compiling, like so:instead of the usual
There might be problems with this solution to do with loading shared libraries at runtime, but I haven't looked into the issue deeply enough to comment.
我之前也遇到过同样的问题,已经解决了,步骤可以参考这个
修复 matlab 上的错误“GLIBCXX_3.4.15”
I had the same problem before, and fixed that, the steps could be found on this
Fixing error "GLIBCXX_3.4.15" on matlab
gcc 版本
4.8.1 (GCC)
和libstdc++.so.6.0.18
也是如此。必须将其复制到我的 ubuntu 机器上的/usr/lib/x86_64-linux-gnu
处。Same thing with gcc version
4.8.1 (GCC)
andlibstdc++.so.6.0.18
. Had to copy it here/usr/lib/x86_64-linux-gnu
on my ubuntu box.出于测试目的:
在原始计算机上,找到该库,复制到与可执行文件相同的目录:
然后将同一库复制到目标计算机,并运行可执行文件:
注意:上面的命令是临时的;这不是一个系统范围的变化。
For testing purposes:
On the original machine, find the library, copy to the same directory as the executable:
Then copy this same library to the target machine, and run the executable:
Note: command above is temporary; it is not a system-wide change.