Посоветуйте альтернативу glibc. Основное требование - малый размер.
Спасибо

Полагаю, что полезных альтернатив скорее всего нет. Буквально на днях с целью научиться чему полезному рассматривал исходники всех ARM C библиотек до которых мог дотянуться - все они как близнецы братья писаны на С без особых изысков :-(. ASMа считай нет. Посему и результат зависеть будет практически только от компилятора их компилирующего. А какие проблемы с размером? Неужели Ваша программа состоит исключительно из вызовов _разнообразных_ clib функций. Обычно сколь-нибудь заметного веса десяток используемых библиотечных функций не имееют.
Как паллиатив можно попробовать использовать исходики библиотеки для написания чего-либо облегченного, но работоспособного в Ваших конкретных условиях.
С целью попробовать повысить бвстродействие и потренироваться, наверное буду в начале следующего года переписывать на ASM (но под IAR) нескоторые библиотечные функции, начиная
с простейших типа memcpy(). Если,что найдете что ASMовское - сообщите пожалуйста.

zltigo, что касается ИАРовских библиотек, то когда я смотрел в своё время исходники для версии 4.20, то уже тогда компилируя отдельные куски с высоким уровнем оптимизации приходил к выводу, что написать вручную на ассемблере короче и быстрее врядли удастся. Тем более, когда речь идёт о простых функциях типа memcpy().
Так вот уже тогда меня всё (или почти всё) устраивало.
Когда же вышла версия 4.30 и разработчики клялись, что существенно улучшили библиотеку, а особенно плавающую точку (ускорили почти вдвое!), и когда я собрав достаточно большой проект обнаружил, что он работает, то я понял, что от добра добра не ищут и вместо того, чтобы пытаться выжать дополнительные наносекунды, следует направить усилия на решение поставленных задач полностью (или почти полностью) доверяя компилятору.
Тем не менее, не спорю, что изучение исходников дало в плане опыта очень многое.
Ведь именно у мастеров и надо учиться.

Прошу прощения если не в тему.

http://sources.redhat.com/newlib/

Практически все свободные библиотеки - newlib,dietlib,uClib - достаточно большие.
Например для функции sprintf() GCC linker добавляет из newlib-1.13.1 почти 34 kB
кода - и это без floating point support! С другой стороны,размер кода,добавляемого
для операций деления,относительно невелик и сравним с кодом библиотек коммерческих
компиляторов.
Поэтому выход видится такой - или применение lib от коммерческих компиляторов(для
IAR ARM можно найти исходники в И-нете),или применение "усеченных" версий для
"тяжелых" ф-ций(sprintf(),sscanf(),...)

Я тоже подозреваю и НАДЕЮСЬ, что не удастся! Закрученнейшие ассемблерные тексты выдает
компилятор при высоком уровне оптимизации. Без оптимизации все в лоб, а оптимизированный -
руками писать замаешся. Эффективность сего с точки пока оценить не могу, но вид внушает надежды.
Хотя, конкретно, на счет memcpy() - ручками играя на пересылках слов+байтов полагаю превзойти.
Ну а плавучку переписывать это чистый садомазохизм, да и не нужна она мне на ARM.

Теперь ближе теме. Коллеге библиотеки, я думаю, действительно следует перекомпилировать для начала. Из прошлого опыта - их обычно собирают без оптимизационных изысков.

В свое время я поступал так (это ещё когда под Watcom-мом ) - критически важные
функции выделял в отдельную библиотеку, при нужде - дизассемблировал - перекомпилировал, или писал сам, или в данном случае - можно из чужих библиотек перенести - от CrossWorks, например, и в строке для линкера - первой была эта моя библиотека.

Вот-вот, я тоже, прежде всего за самостоятельную сборку библиотеки. Если ОС точно не используется - то задача тривиальная (оставьте только минимум библиотечных модулей для решения Ваших задач). Посмотрите какой из модулей тянет за собой большой хвост (так, например, упоминаемый sprintf требует все операции с плавающей точкой, а если, например float-деление больше нигде не используется - то может быть и sprintf пожертвовать, написав свою функцию преобразования по задаче и т.п.). Если же Вы используете в своей разработке операционную систему - то посложнее. Но и в этом случае можно найти "лишние детали" в стандартной библиотеке.