Хотя я не вижу большого смысла, вот он:
for i in xrange(0, len(prices)):
exec("price%d = %s" % (i + 1, repr(prices[i])));
Попытайтесь заменить (строка Md5.c 41)
typedef unsigned long int UINT4;
typedef uint32_t UINT4;
(включайте stdint.h в случае необходимости),
На машине на 64 бита длинное целое (обычно) 64 бита длиной вместо 32
РЕДАКТИРОВАНИЕ:
Я примерил Opteron на 64 бита, это решает проблему.
Машина, которая, кажется, не работает другая архитектура (32-разрядный по сравнению с 64-разрядным), чем другие? Если реализация MD5 зависит от размера машинного слова (я не проверил код), это может заставить хеш отличаться.
Различные компиляторы могут иметь разные уровни стандартного соответствия. При столкновении с нестандартным компилятором, у Вас могут быть трудные времена, видя, что хорошо протестированный код был скомпилирован во что-то работающее совершенно отличающийся.
Это может также произойти, что целевая система является 64-разрядной, и код имеет 64-разрядные проблемы мобильности.
Единственный способ решить проблему состоит в том, чтобы отладить, где точно две версии Вашего кода ведут себя по-другому.
Извините, нет. Если я компилирую это и выполняю его на моем поле linux x86, это приводит к тому же результату как md5sum утилита:
peregrino:$ md5sum csrc/Md5.c d27fd5f04426a3ccb2390d7517f21b9c csrc/Md5.c peregrino:$ bin/Md5 csrc/Md5.c d27fd5f04426a3ccb2390d7517f21b9c csrc/Md5.c
На моем x64 поле:
sandiego:$ bin/Md5 src/Md5.c 09679964608e3335c5c3e14572373eef src/Md5.c
Таким образом, это, действительно кажется, проблема на 64 бита, а не проблема Linux.
Вы удостоверялись, что читаете в режиме двоичного счета? Иначе новая строка будет преобразована по-другому в другой ОС.