问题标签 [glibc]

有没有办法从 .a 文件中找出预期或在构建 .a 时使用的 glibc 版本？

在此脚本的输出结束时，我收到以下错误消息：

* 检测到 glibc * perl: munmap_chunk(): 无效指针: 0x0000000000b362e0 *** ======= 回溯: =========
/lib64/libc.so.6[0x7fb84952fc76]
...
= ====== 内存映射：========
00400000-0053d000 r-xp 00000000 08:01 182002 /usr/local/bin/perl
...

这是由于错误吗？

perl -V:

我的perl5（revision 5 version 12 subversion 0）配置总结：

平台：
osname=linux,osvers=2.6.31.12-0.2-desktop,archname=x86_64-linux uname='linux linux1 2.6.31.12-0.2-desktop #1 smp preempt 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 gnulinux 'config_args='-Dnoextensions=ODBM_File' 提示=推荐，useposix=true，d_sigaction=define useithreads=undef，usemultiplicity=undef useperlio=define，d_sfio=undef，uselargefiles=define，usesocks=undef use64bitint=define，use64bitall =define, uselongdouble=undef usemymalloc=n, bincompat5005=undef
编译器：
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-严格别名 -pipe -fstack-protector -I/usr/local/include'ccversion='', gccversion='4.4.1 [gcc-4_4-branch revision 150839]', gccosandvers='' intsize=4, longsize= 8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t= 'off_t'，lseeksize=8 alignbytes=8，prototype=define
链接器和库：
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 libs= -lnsl -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.10.1.so，so=so，useshrplib=false，libperl=libperl .a gnulibc_version='2.10.1' 动态链接：dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 - L/usr/local/lib -fstack-protector'

此二进制文件的特征（来自 libperl）： 编译时选项：PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
在 linux 下编译 2010 年 4 月 15 日 13:25:46 @INC: /usr/local/lib/perl5/site_perl/5 0/x86_64-linux /usr/local/lib/perl5/site_perl/5.12.0 /usr/local/lib/perl5/5.12.0/x86_64-linux /usr/local/lib/perl5/5.12.0 。

当我尝试启动 android 1.6 或 2.1 时，我得到了这个跟踪。Android 1.5 运行良好。我尝试重新安装每个 SDK，但无法使其正常工作。我用 Eclipse 插件创建了那些 AVD。

我正在尝试构建一个可以在多个 Linux 发行版上运行的二进制包。它目前是在 Ubuntu 10.04 上构建的，但在 Ubuntu 8.04 上失败并出现以下错误：

解决此问题的首选方法是什么？有没有办法在新盒子上安装旧 glibc 并针对它进行构建，还是我必须在旧发行版上构建？如果我针对旧的 glibc 构建，它会在新的 glibc 上工作吗？

或者，是否只有一些方便的编译器标志或包我可以安装来解决问题？

printf/fprintf/sprintf 系列在其格式说明符中支持宽度字段。我对（非宽）字符数组参数的情况有疑问：

宽度字段应该表示字节还是字符？

如果 char 数组对应于（例如）原始 UTF-8 字符串，那么（正确的事实）行为是什么？（我知道通常我应该使用一些宽字符类型，这不是重点）

例如，在

该函数是否应该尝试仅输出 5 个字节（纯 C 字符）（如果两个字节导致文本字符，您将承担错位或其他问题的责任）？

还是应该尝试计算数组的“文本字符”的长度？（解码它......根据当前的语言环境？）（在这个例子中，这相当于发现字符串有 4 个 unicode 字符，所以它会添加一个填充空间）。

更新：我同意答案，printf 系列不区分纯 C 字符和字节是合乎逻辑的。问题是我的 glibc 似乎没有完全尊重这个概念，如果之前已经设置了语言环境，并且如果有（今天最常用的）LANG/LC_CTYPE=en_US.UTF-8

一个例子：

因此，即使设置了非 POSIX-C 语言环境，printf似乎仍然具有计算宽度的正确概念：字节（c 普通字符）而不是 unicode 字符。没关系。但是，当给定一个在他的语言环境中不可解码的 char 数组时，它会默默地恐慌（它中止 - 在第一个 '|' 之后没有打印任何内容 - 没有错误消息）......只有当它需要计算一些宽度时。我不明白为什么它甚至在不需要/必须的时候尝试从 utf-8 解码字符串。这是 glibc 中的错误吗？

使用 glibc 2.11.1 (Fedora 12) (也是 glibc 2.3.6) 测试

注意：这与终端显示问题无关 - 您可以通过管道检查输出 od ：$ ./a.out | od -t cx1这是我的输出：

更新 2（2015 年 5 月）：这种有问题的行为已在较新版本的 glibc 中得到修复（似乎从 2.17 开始）。有了glibc-2.17-21.fc19它对我来说没问题。

每当我在最后运行我的程序fclose(outputFile); 时，都会出现错误。glibc 检测到...损坏的双链表

不过，令人困惑的是，我在它的fclose(inputFile);正上方，它工作正常。有什么建议么？

gcc 在 .c 文件上工作正常，但在 .cpp 文件上失败，说：

$ gcc: 错误试图执行 'cc1plus': execvp: 没有这样的文件或目录

g++ 失败说：

$ g++: 找不到命令。

我应该怎么做才能编译 C++ 文件？

1. 根据 2008 年的帖子（我现在找不到），glibc 堆检查在多线程环境中不起作用。现在还是2010年的情况吗？
2. 默认情况下是否启用堆检查？（GCC 4.1.2）？我没有设置 MALLOC_CHECK_，不知道调用 mcheck()，但有时仍会收到带有回溯的双重免费 glibc 错误。也许它是由一些编译标志启用的？

当我在我的 Ubuntu Lucid 10.04 PC 上编译某些东西时，它会链接到 glibc。Lucid 使用 2.11 的 glibc。当我在另一台使用较旧 glibc 的 PC 上运行此二进制文件时，该命令失败，提示没有 glibc 2.11 ...

据我所知 glibc 使用符号版本控制。我可以强制 gcc 链接到特定的符号版本吗？

在我的具体使用中，我尝试为 ARM 编译一个 gcc 交叉工具链。

是否可以告诉 valgrind 忽略某些库？特别是 glibc 库..

实际问题：我有一些在正常执行中运行良好的代码。无泄漏等。

当我尝试通过 valgrind 运行它时，我得到核心转储和程序重新启动/停止。

Core 通常指向 glibc 函数（通常是 fseek、mutex 等）。我了解不兼容的 glibc / valgrind 版本可能存在一些问题。

我尝试了各种 valgrind 版本和 glibc 版本，但没有运气。有什么建议么？