strtod(） 的可怕错误:glibc-2.13 不向后兼容 glibc-2.9

Horrid error with strtod(): glibc-2.13 NOT backwards compatible with glibc-2.9?

本文关键字：glibc-2 错误 strtod      更新时间：2023-10-16

我正在研究需要在几个不同的嵌入式平台上运行的C和C++程序，为此我有交叉编译器，因此我可以在x86桌面上进行构建。

我对某些函数有一个可怕的问题，例如"strtod(("。这是我的简单测试程序： 

#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
  {
  if ( (argc < 2) || (NULL == argv[1]) ) return 0; 
  double myDouble = strtod(argv[1], NULL);
  printf("nValue: %fnn", myDouble);
  return 0;
  }

通常，我使用动态链接构建所有程序，以使二进制文件尽可能小。以上在x86和Power PC上工作正常。然而，在 Arm 系统(带有 Debian 的 BeagleBoard xM(上，strtod(( 行为不正常(程序总是输出"0.000000"(。

我尝试使用选项"-static"构建程序，这适用于小猎犬： 

root@beaglexm：/app# ./test.dynamic 1.23值：0.000000  [动态链接版本 - 错误！！root@beaglexm：/app# ./test.static 1.23值：1.230000  [正确！！]

我还在BeagleBone Black上进行了测试，它的分布略有不同。两个版本(静态和动态(在BBB上都运行良好。

在

库中翻找，我发现了以下版本号：

交叉编译器工具链：libc-2.9.so

BeagleBoard XM(不起作用(：

libc-2.13.so

小猎犬骨黑(作品！(：libc-2.16.so

所以我的交叉编译器正在针对旧版本的 glibc 构建。我在几个地方读到glibc应该是向后兼容的。

我只考虑过静态链接libc，但根据这个问题，除非所有库都是静态链接的，否则这是一个坏主意。

静态链接一切确实有效，但系统存在严重限制，这意味着我需要保持二进制文件尽可能小。

任何想法会导致strtod(((和类似函数(出现可怕的问题和/或为什么glibc 2.13不向后兼容？

编辑：我没有提到"soname"(即顶级名称(在所有平台上都是相同的："libc.so.6"从我对文档的阅读来看，"soname"中 .so 后面的数字是主要版本，只有在界面更改时才更改 - 因此所有这些版本都应该兼容。出现在实际文件名中的 .so 前面的数字(如上所示，通过符号链接找到(是次要版本。请参阅：链接

通常版本号反映了兼容性。 出现在.so和下一个点之间的数字表示主要修订版，不保证与任何其他主要修订版兼容。

后面的数字(只有当您点击符号链接时才能看到(表示次要修订。 这些可以互换使用，符号链接就是用来做到这一点的。 该程序链接到libc.so.6或其他任何东西，在实际文件系统上，libc.so.6是指向(例如(libc.so.6.12的符号链接。

glibc 试图保持兼容性，即使是跨主要修订版，但有时他们只需要接受重大更改。 通常，当发布新版本的 C 或 POSIX 标准并且函数签名以破坏二进制兼容性的方式更新时。

如果更改，出现在.so之前的任何数字也会破坏兼容性;这些数字通常表示程序的完全重写。 例如glib vs glib2 . 不关心 libc。

该工具ldd对于调查库依赖项和发现库的实际加载时间非常有用。

相关文章：