LINUX.ORG.RU

Первый публичный релиз musl

 dietlibc, , , ,


0

5

В списке рассылки uClibc Рич Фелкер (Rich Felker) объявил о первом публичном выпуске musl — новой реализации библиотек общего назначения языка C. Основные отличия от существующих решений:

  • В отличие от glibc, musl легче и конструктивно проще. Компиляция musl из исходных кодов на Intel Atom D510 занимает менее 40 секунд. Поддержка локалей ограничена UTF-8, что позволяет применять более прямые подходы и улучшает производительность. stdio также проще, меньше и, во многих случаях, ощутимо быстрее. В терминах big-O большинство используемых операций musl сопоставимы с glibc. При этом все алгоритмы более оптимальны по использованию памяти, в частности, многие операции, потенциально рискующие не завершиться из-за нехватки памяти в glibc, удачно сработают в musl, благодаря её более эффективному распределению O(1).
  • В отличие от dietlibc, разработчики не стремятся урезать каждый возможный байт, жертвуя производительностью и корректностью. musl не пытается отвратить вас от использования stdio, тредов, регулярных выражений и т.д., а стремится сделать эти элементы эффективными (размер бинарников, потребление памяти в рантайме и производительность).
  • В отличие от uClibc, musl имеет стабильное, хорошо определённое ABI. Особое внимание было уделено тому, чтобы не создавать лишних зависимостей между компонентами библиотеки, таким образом, при статической линковке будет использован только необходимый код.
  • В отличие от Google Bioinc (Android libc), musl не жертвует совместимостью со стандартами ради уменьшения размера библиотеки и не основан на старом коде BSD.
  • В отличие от всех вышеупомянутых реализаций, musl объединяет все стандартные функции в одну библиотеку (.a или .so), что значительно уменьшает время запуска, количество используемой памяти, упрощает процесс обновления и нивелирует риски несовпадения версий.

На данный момент musl реализует следующие стандарты:

  • ISO C99;
  • IEEE754;
  • POSIX 2008 base;
  • большую часть XSI и других из группы POSIX;
  • никаких заметных усилий на поддержку устаревших SVID и BSD направлено не было.

Целевая аудитория:

  • разработчики встраиваемых систем;
  • разработчики легковесных дистрибутивов Linux;
  • разработчики rescue disk;
  • любой, кто хочет собрать статически слинкованный бинарник для безболезненной установки на любой ОС с ядром Linux;
  • любой, чья программа может вызываться десятки или сотни тысяч раз в секунду и ей необходим минимальный оверхэд по времени старта и используемой памяти.

Текущий выпуск работает на платформе x86 с ядром Linux не старее 2.6 (список платформ будет увеличен в следующих релизах).

Полный набор .a имеет размер 160k, а .so — 220k. Подробную сравнительную таблицу возможностей musl и других реализаций можно посмотреть на сайте проекта.

Скачать

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: Dendy (всего исправлений: 5)

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

1. Скоростью своего линукса вполне доволен. Уж побыстрее винды будет. Причём любой из.

2. Ну нашли несколько уязвимостей в glibc, пофиксили. Больше вроде бы уже не находят.

3. А как же совместимость со всем набранным софтом? Придётся перекомпилировать каждую программу для нового варианта.

И кстати, разве этот musl для десктопов? Он же для embedded-девайсов.

d1337r
()

Если сделают под различные mips и arm,то будет совсем круто.

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

Учись читать:

«musl, pronounced like “mussel” or “muscle”, is an implementation of the C/POSIX standard library intended for use on Linux-based systems, licensed under the GNU LGPL version 2.1 or later»

anonymous
()

>Полный набор .a имеет размер 160k, а .so — 220k.

Ну на самом деле, это вообще странная пузомерка. Типа как «интересные обои в BolgenOS». :)
Очень многое зависит от флагов компиляции, от применения inline в коде (и во флагах компиляции). То есть, конечный бинарник может быть типа «больше по размеру», но реально исполняться быстрее из-за многочисленных inline и флагов типа -fexpensive-optimizations (или просто -O3).

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

ну вообщем тут сказать ничего не могу. Но не поленитесь, взгляните на табличку и комментарии к ней, думаю найдете ответы на некоторые вопросы.

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

>>Полный набор .a имеет размер 160k, а .so — 220k.

Ну на самом деле, это вообще странная пузомерка. Типа как «интересные обои в BolgenOS». :)


Очень многое зависит от флагов компиляции, от применения inline в коде (и во флагах компиляции).


]$ ls -l /lib/libc-2.7.so
-rwxr-xr-x 1 root root 1294572 2009-01-04 21:11 /lib/libc-2.7.so

Ты хочешь сказать, что, в зависимости от флагов компиляции, код может быть в 5.5 раз больше?

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

>> и да, если заменить в системе glibc на musl, то придётся перекомпилировать всё?)

только в кошмарном сне

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

>код может быть в 5.5 раз больше

Может, нужно таки заглянуть в табличку и посмотреть, чего мули (в отличие от глибс) делать НЕ умеют.

Одни математические функции С99 чего стоят...

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

Одни математические функции С99 чего стоят...

Какие?

mashina ★★★★★
()
Ответ на: комментарий от Lonli-Lokli

умну такие мысли проскакивают переодически, но ауры красноглазия не хватает

seed_stil ★★
()

В таблице по ссылке сравнение с glibc даже не проводится. Что это значит, объясните, кто в теме, плз. Я уже понял, что на десктоп это тащить ещё рано, но что в перспективе?

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

>> код может быть в 5.5 раз больше

Может, нужно таки заглянуть в табличку и посмотреть, чего мули (в отличие от глибс) делать НЕ умеют.

То есть размеры бинаря определяются не опциями компилятора, а функционалом и методом его реализации. На это и намекала пузомерка.

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

ХА-ХА, облом вышел, не удастся на чужом труде нажиться, да?

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

> Я уже понял, что на десктоп это тащить ещё рано, но что в перспективе?

Ну какой нафиг десктоп? Ей пока в initrd только перспектива есть.

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

>линух вообще запустится?
Нет конечно =) Но я надеюсь сабж не прибили к нему. Интересен он просто как кодовая база.

GAMer ★★★★★
()

тем, кто спрашивал «что с ним работает?»

What programs work with musl?

Here's a somewhat diverse list of programs/libraries I have built and tested:

* GNU binutils 2.20.1 * GCC 3.4.6 (with «fixinc.sh» stripped out) * GNU Make 3.82 * Bash 4.1 * ncurses 5.7 * GLib 2.26.1 * MaraDNS 1.4.05 * popa3d 1.0.2 * DropBear 0.52 * FFmpeg SVN * OCaml 3.12.0 (non-optimizing) * Mutt 1.5.21 * Nano 2.2.6 * Irssi 0.8.15 * Screen 4.0.3 * Emacs 23.2 (with moderate tweaking to fix glibc assumptions) * BusyBox 1.18.2 (not all applets; moderate tweaking)

While not all BusyBox applets work yet, it is possible to build enough to have a fully musl-hosted system.

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

>«мелкий»? 64K RAM?
Угу, а то и меньше. Даже если брать достаточно мощные MCU, то среди них хватает и с меньшей памятью. Но на них обычно заводятся более специализированные РТОС с требованиями около 30-90кб. А уж если использовать XIP, то расход памяти вообще смешной.

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

и? ну вот я знаю целое семейство распространенных embedded девайсов работающих с gcc 3.4.4-3.4.6

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

посыл был в том, что embedded больше и не нужно, musl и не позиционируется как основная библиотека для десктопа.

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

попробуй прочитать текст новости, после слов «целевая аудитория»

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

> опять огороженный GPL

Кто я чем, а рабы джобса - об огораживании. На GPL плеваться будешь тогда, когда исходники macosx опубликуют под bsdl.

Manhunt ★★★★★
()

благодаря лучшей реализации пространства O(1)

wat-wat-wat??? гильбертово пространство - знаю, банахово пространство - знаю, даже евклидово пространство - знаю, O(1) - не знаю... отстал от жизни?

shty ★★★★★
()

> Поддержка локалей ограничена UTF-8

На полноценный юникод на Западе решено было положить большой и волосатый болт? Печально. Прогрессом это назвать трудно

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

>> Поддержка локалей ограничена UTF-8

На полноценный юникод на Западе решено

utf8 и есть полноценный юникод...

angel_il ★★★★
()

что-то название не очень говорящее, я по заголовку совсем не про libc подумала, спасибо. надо будет поэксрепиментировать со сборкой разных мелких программ.

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

> utf8 и есть полноценный юникод...

Это поэтому столько кактусов съедается при парсинге документов с учётом и без учёта BOM?
Когда в системе одни текстовые редакторы по-умолчанию ставят метку, другие не ставят. Начинается цирк

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

>>Полный набор .a имеет размер 160k, а .so 220k.

пролетает наверное мимо мелкого embedded

Сам-то понял, что ляпнул? Или тебя смущает «160k», а про то как «линкуется» статическая библиотека - «ни в зуб ногой»?

Led ★★★☆☆
()

А на Gentoo и ее производные портеж есть? Это единственный шанс раскрутить сабж. А ведь идея не просто хорошая, а еще и весьма актуальная. Особенно приятно, что локали исключительно в UTF-8. Давно назрела необходимость выкинуть все неюникодовские локализации из абсолютно всех приложений.

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

Это поэтому столько кактусов съедается при парсинге документов с учётом и без учёта BOM?

Какое отношение порядок байтов имеет к utf8? И при чем тут кактусы?

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

UTF-8, это побайтовая кодировка. она не бывает LE или BE, так как для декодирования символа надо учитывать каждый следующий байт. т.е. для латиницы это всегда 1 байт, для кириллицы 1+1, для китая 1+1+1+1.

очевидно же для «маленьких» решений, вроде роутеров, DVR, Home-NAS, и ещё более специальной электроники, нет необходимости поддерживать 10ки разных кодировок, а сделать выбор в сторону экономного и функционального варианта с UTF-8.

ну а если вам позарез нужен китайский текст или cp1251, вы можете его добавить сами: код библиотеки небольшой и несложный .

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

глючновато, собрала bash,
O_NDELAY пришлось определять вручную,

статически собранный бинарник баша почему-то не запустился из sshd при переносе на другую машину...

но начинание хорошее.. для первого публичного релиза сойдет.

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

Но я надеюсь сабж не прибили к нему

Судя по новости как раз прибит :)

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

Приветствую тебя, о гуру! Про линковку я естественно в курсе, и если бы светлоокий обратил свой взор на мои посты ниже, он бы узрел, что смущает именно размер, потому как во многих проектах ОС libc(правда обычно кастрированный донельзя) вообще встроен в ядро. И даже более того, часто весь софт вместе с либами и ядром собирается в один имидж.

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

>Учись читать:

«musl, pronounced like “mussel” or “muscle”


Ну, это пусть пендоссы так произносят. Повелеваю по русски читать название, как: „Мюсли“. :)

И, хотя, я мюсли не ем, думаю эти придутся по вкусу. :)

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

Всё просто.

> В таблице по ссылке сравнение с glibc даже не проводится. Что это значит, объясните, кто в теме, плз. Я уже понял, что на десктоп это тащить ещё рано, но что в перспективе?

glibc это для десктопов/серверов. Точнее, для машин с операционной системой «общего назначения». Для embedded и прочих «реалтаймов» (подразумеваются системы, критичные к размерам памяти, отработке событий и прочая-прочая-прочая) glibc как правило, не очень хорош. По этой причине для такого рода сложных случаев используются всякие-разные альтернативы glibc.

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

Да. В ногу.

> в ногу со временем, как говорится

Рекомендую сравнить размеры генерируемого кода для 3.4.6 и для 4.4.4. Рискуете удивиться. _Сильно_.

До последнего использовал 2.95.2. Теперь уже оно ни как, так что, 3.4.6 здесь в точку.

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

Не смотрел пока.

> Хорошо, а как обстоит дело с gcc 4.5

Врать не буду. Но боюсь что не лучше. Надо будет toolchain собрать да затестить на двелопментской борде.

Кому интересно, то как собрать нужный toolchain from scratch тут -> http://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc?action=AttachFile или у Дэна Кегеля -> http://www.kegel.com/crosstool/crosstool-0.43/doc/crosstool-howto.html

4.4.4 собирал по -> http://www.gnu.org/software/hurd/toolchain/cross-gnu.html

Ну и самая стартовая точка (для сааамого начала) -> http://www.linuxjournal.com/article/9904?page=0,0

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

> O_NDELAY пришлось определять вручную,

статически собранный бинарник баша почему-то не запустился из sshd при переносе на другую машину...


но начинание хорошее.. для первого публичного релиза сойдет.


Я тоже «за» всеми лапами. Можно даже попробовать построить buildbot, который тащит из гита новые коммиты, пересобирает все и тестирует. Только гит автор все никак не сделает, хотя на гитхабе это можно сделать за полчаса не спеша под плюшечки.

А хорошее начинание это потому, что любая либц, в которой нет Дреппера, лучше, чем либц с Дреппером.

“Fine. Whatever. I'll revert it, assholes.”

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