GNU C: сбой atof(), strtof() и strtod() (Debian для BeagleBoard)

Question

У меня есть некоторый код C, который преобразует строку ASCII в удвоение с помощью strtod(...). Программа скомпилирована для x86 (отладка), ARM и PowerPC (встроенные целевые системы). Плата ARM на самом деле представляет собой BeagleBoard xM, на котором установлен Debian.

Я обнаружил, что strtod() неправильно конвертирует значения в системе ARM / Debian. Фактически все значения, которые я попробовал, вышли как 0,000.

Для демонстрации я написал следующую очень простую тестовую программу:

#include <stdio.h>
#include <stdlib.h>

int main(const int argc, const char **argv)
  {
  const char myString[] = "123 ";
  char *myEnd1 = NULL;
  char *myEnd2 = NULL;

  float  fValue = 0;
  double dValue = 0;

  dValue = atof(myString);

  printf(   "Using atof():\n"
            " String:  %s\n"
            " Double:  %lf\n",
             myString,
             dValue                           );

  fValue = strtof(myString, &myEnd1);
  dValue = strtod(myString, &myEnd2);

  printf(   "Using strtof() / strtod():\n"
            " String:  %s\n"
            " Float:   %f (%d)\n"
            " Double:  %lf (%d)\n",
            myString,
            fValue, (myEnd1 - myString),
            dValue, (myEnd2 - myString)             );

  return 0;
  }

Все они были скомпилированы на компьютере x86 под управлением Ubuntu (фактически на виртуальной машине). У меня есть кросс-компиляторные наборы инструментов для компиляции PowerPC и ARM.

В системах x86 и PowerPC выходные данные соответствуют ожидаемым, т.е.

Using atof():
 String:  123 
 Double:  123.000000
Using strtof() / strtod():
 String:  123 
 Float:   123.000000 (3)
 Double:  123.000000 (3)

Тем не менее, при запуске на BeagleBoard, я получаю это:

Using atof():
 String:  123
 Double:  0.000000
Using strtof() / strtod():
 String:  123
 Float:   -0.372039 (3)
 Double:  0.000000 (3)

Да??? Я что-то упустил глупый? Обратите внимание, что указатели "myEnd" как раз и показывают, что strtod() и strtof() действительно нашли первый нечисловой символ и, следовательно, конец числа. Они сообщают правильное количество символов в числе в обоих случаях (3), но преобразованное значение неверно. Я не думаю, что это локальная проблема, так как нет запятой, в которой можно запутаться.

РЕДАКТИРОВАТЬ:

Я просто перекомпилировал тестовую программу с опцией "-static". Конечно, это сделало бинарный файл намного больше, но теперь он корректно работает на целевой платформе ARM.

Я немного запутался в том, как работают библиотеки. Кроме того, я не могу точно вспомнить, как я построил свой кросс-компилятор. Вероятно, он не был собран из того же источника, что и Debian Linux, установленный на целевой плате.

Итак, означает ли необъяснимое поведение atof() и т. Д., Что библиотека, ожидаемая динамически связанным исполняемым файлом, не совпадает с реальной библиотекой в ​​системе? Я удивлен, что это не вызвало худших проблем. Мы работаем с этой системой в течение года, и пока это единственная странная ошибка, с которой мы столкнулись.