>glibs-devel уже стоит. glibc-devel (через с, а не s), странно тогда, проверьте список файлов этого пакета, среди них должен быть libc.a, если нет поищите среди пакетов с "glibc" в названии, т.к. это либа из глибсы.
>Смысл в чем. Собственно, эта проблема наверно достойна отдельной темы. Есть некий
>комп, на котором собранные на моем компьютере исполняемые файлы не исполняются.
>Появляется ошибка floating point exception, хотя на моем конечно все работает
>и дело не в коде. Я попробовал собрать на своем статически,
>чисто ради эксперимента, и натолкнулся, что не получается у меня это
>сделать. На компе (там довольно древнее ПО), на котором не работали
>мои исполняемые файлы проблему я поборол, может не совсем красивым способом,
>просто заменив 2 библиотеки (libc и ld-linux), разобравшись что программа "падает"
>именно в их коде, что тоже очень странно, на свои (имеется
>в виду со своего компьютера), и файлы начали запускаться.
Подход не правильный изначально.
Нельзя просто так взять перенести бинарь запустить его и радоваться. Такое возможно когда у вас на двух хостах идентичные конфигурации софта и ключи компиляции по архитектуре совместимые. Что используется например для варианта build-хоста имеющего такую же конфигурацию и версии всех компонентов что и production-хост. На нем обычно собирается бинарный пакет и и далее устанавливается на production (rpm-based distributives тому пример).
Если же как в вашем случае хосты имеют разную конфигурацию по версиям ПО, их параметрам, на второй машине видимо архитектура более старая, отличная от той где вы собираете бинарь,
это приводит в различиях в ABI и т.п., о чем и говорят проблемы с ld-linux и libc, как следствие странные ошибки. То что вы сделали просто заменив их (как понимаю просто обе .so скопировали), не решение, т.к. вы может быть на первый взгляд и решили проблему, а на самом деле создали ситуацию когда в дальнейшем полезут странные и неотлавливамые ошибки в самых неожиданных местах и в вашей программе и в других процессах системы.
По хорошему следует либо ключами компилятора задавать более архитектурно безопасный вариант компиляции (если разница в ПО незначительно и есть backward compability между этими версиями), либо, что еще лучше, компилировать и собирать прямо на целевой машине (если нет build хоста с идентичной конфигурацией).
Статическая сборка не решит всех проблем в данном случае - просто ошибки будут иные, в другом месте и еще более непонятные.
Вариант для распечатки
Программирование под UNIX (Public)
(??) on 05-Дек-08, 14:10 
