LINUX.ORG.RU

Релиз uClibc 0.9.33

 , ,


0

2

Спустя полгода со дня прошлого релиза, состоялся релиз uClibc 0.9.33.

Цитата из Википедии

uClibc была разработана для поддержки uCLinux (специальная редакция ядра Linux, способная работать без блока управления памятью [MMU]) и таким образом подходящая для микроконтроллеров. (буква u есть адаптация греческой буквы µ, означающей «микро»).

uClibc требует намного меньше ресурсов, чем GNU C Library (glibc), которая распространяется с популярными дистрибутивами Linux, составляя «GNU/Linux». В то время как glibc специализируется на полной поддержке всех мыслимых стандартов C через поддержку широкого спектра аппаратных платформ (железа ПК) и ядер множества ОС, uClibc фокусируется на встраиваемом Linux. Функции uClibc могут включаться или выключаться в соответствии с потребностями в свободных ресурсах устройств, на котором установлена данная библиотека.

uClibc может запускаться как на системах с MMU так и без него. Библиотека поддерживает i386, x86-64, ARM (big/little endian), AVR32, Blackfin, h8300, m68k, MIPS (big/little endian), PowerPC, SuperH (big/little endian), SPARC и v850 процессоры.

За ChangeLog спасибо true_admin:

  • Улучшение работы threads;
  • Удаление deprecated-кода;
  • Улучшения в системе сборки;
  • Подчистка опечаток и отладочных сообщений;
  • Улучшение обработки аварийных ситуаций;
  • Поддержка новых методов шифрования;
  • Улучшения для архитектуры x86_64;
  • Исправлена работа с переходом на летнее время;
  • И многое другое!

ChangeLog

>>> Сайт проекта

★★★★★

Проверено: post-factum ()
Последнее исправление: ZenitharChampion (всего исправлений: 1)

Ответ на: комментарий от anonymous

канонiчный способ — курить USE-флаги в профилях ... фактически (оверлей=репозиторий)+/etc/paludis/bashrc=профиль.

Я поонял, нельзя.

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

ну почему нельзя, вот в Gentoo/FreeBSD это по факту сделали — там BSD libc совсем другой чем glibc, и это нормально отрабатывается. Как-то так нужно делать, если iсильно приспичит (или USE-флаги для выбора libc + Gentoo Prefix, софт с uclibc устанавливать в EPREFIX).

Другой вариант — собрать руками кросстулчейн, тулчейном uclibc софт и ставить в /usr/local (мало отличается от Gentoo Prefix). И иметь в / — glibc софт, в /usr/local/ — uclibc.

Другое дело, что смысла особого нет, т.к. Линукс софт может быть сильно завязан на glibc.

anonymous
()
Ответ на: комментарий от anonymous

Потом, в Gentoo portage есть такая штука, как injected пакеты. Это пакеты, которые portage считает уже установленными, как есть. Когда ставится например sys-apps/hello, он неявно зависит от system, то есть, gcc, glibc, autotools. Можно поставить другой libc, и сделать glibc injected. Тогда portage будет считать, что glibc уже установлен, и не будет его пересобирать заново из исходников. После чего ставим sys-apps/hello, который теперь будет зависеть от другого libc. Другое дело, что при обновлении glibc теперь sys-apps/hello сломается, и его надо будет заново пересобирать, через portage — и тогда он пересобранный будет зависеть уже от нового glibc, или через Gentoo Prefix — и тогда заново пересобрать от нового libc. Хотя разводить зоопарк из разных либц — неправильно. Правильно, если зависимости от разных либц корректно указывать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.