Релиз uClibc 0.9.33

Вот меня интересует один вопрос, почему в Android используется bionic, а не uClibc. Ладно бы bionic все умел, но это изначально урезанная библиотека.

Функции uClibc могут включаться или выключаться в соответствии с потребностями в свободных ресурсах устройств, на котором установлена данная библиотека.

это вообще как?

Вот меня интересует один вопрос, почему в Android используется bionic, а не uClibc

http://en.wikipedia.org/wiki/Bionic_(software)

man #ifdef

ах вот оно как, оказывается.

Если собрать Ububtu только на uClibc, во сколько раз станет быстрее?

будет медленней, компактный размер достигается в том числе из-за отказа от оптимизаций

лицензия?

Если собрать Ububtu только на uClibc

Выхватишь много лулзов из-за отвалившейся функциональности.

Если собрать Ububtu только на uClibc, во сколько раз станет быстрее?

(устало) Посмотрите, Вальтер, чего только Ваши люди не придумают, чтобы Gentoo не ставить...

Могу расшифровать:

Ububtu и быстрее - это оксюморон. Критерий комплектации Убунты - это чтобы у любой домохозяйки с вероятностью 99% всё завелось и подхватилось из коробки. Поэтому туда и понапихано всё, что только можно.

Если нужно побыстрее, есть 2 способа: 1) поставить Убунту и начать от неё отсекать всё лишнее, как скульптор; 2) выбрать другой дистрибутив. А идея пересобирать дистрибутив для домохозяек на библиотеке для микроконтроллеров - это не способ, это ССЗБ.

...или это уже у меня (а заодно и двух ораторов выше по тексту) с чувством юмора совсем плохо стало...

В этой каше кривого быдлокода fmemopen хоть починили?

(устало) Посмотрите, Вальтер, чего только Ваши люди не придумают, чтобы Gentoo не ставить..

А как в вашем Gentoo glibc поменять на что-нибудь другое?

Я такой задачи не ставил. Просто когда я последний раз сравнивал - дефолтная Gentoo (пусть даже с glibc) работала намного быстрее дефолтной убунты.

А как в вашем Gentoo glibc поменять на что-нибудь другое?

Вот один из вариантов: http://judepereira.com/blog/going-embedded-with-mgentoo/

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

КО подсказывает, что в этом вменяемом дистре кроме как любования скоростью делать больше ничего нельзя, ибо в репах гуляет ветер и комьюнити состоит из 3.5 красноглазиков, которых не интересует ничего, кроме иде для лиспа

у убунты тоже есть netinstall, как и у дебиана, что бы не отсекать, а только наращивать необходимое

КО подсказывает, что в этом вменяемом дистре кроме как любования скоростью делать больше ничего нельзя, ибо в репах гуляет ветер и комьюнити состоит из 3.5 красноглазиков, которых не интересует ничего, кроме иде для лиспа

неплохо бы увидеть подтверждение.

>> КО подсказывает, что в этом вменяемом дистре кроме как любования скоростью делать больше ничего нельзя, ибо в репах гуляет ветер и комьюнити состоит из 3.5 красноглазиков, которых не интересует ничего, кроме иде для лиспа

неплохо бы увидеть подтверждение.

Зачем? Все и так знают, что до Ubuntu линукс был консольный, чёрный и страшный. И всё в нём делалось клавиатурой, а не мышкой. И то, что в федоре есть иксы, это лишь необходимость, вызванная популярностью Ubuntu. Марк Шаттлворт лично летал за иксами в космос, портировал FireFox, и написал код пакетной системы DEB и Synaptic. До Ubuntu линукс был системой для бородатых одминов и ничего в нём не было, кроме среды разработки для лиспа и браузера по фидонету.

КЭП намекает: собрать stage1/stage2 самому или воспользоваться готовым stage3-uclibc(проект ведется ЕМНИП полуофициально каким-то испанцем или португальцем)

я пользовал официальный стейдж 2008 года, обновлял, патчил и напильником дорабатывал. Сейчас много всего повыходило нового, нет времени натягивать патчи для uclibc чтобы всё работало, поэтому у меня домашний сервер до сих пор на uclibc-0.9.31

скажи это количеству пакетов в гентушном портеже(оверлеи не в счет). А потом сравни, допустим, с количеством пакетов в том же ынтерпрайзном CentOS. Чуешь разницу?

Сарказм прочитан и оценен. Зачет :-)

Обалдеть. Кайф! Это моя основная standard C Library же!!!

git pull uclibc-git... branch: master - already up-to-date (v0.9.32-rc3-289-ge288fdc)

commit e288fdca5828d068b42372b133dd7b038e2bee42
Author: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Date:   Wed Feb 1 23:52:39 2012 +0100

    bump version to 0.9.34-git
    
    Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

commit 8c0b2c2886479b39cb345491fc0fa279d6d4b4bb
Author: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Date:   Wed Feb 1 22:21:04 2012 +0100

    Release 0.9.33
    
    Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

commit 7c721d31e4b7a0bdf6f803b8e7c38996bf60b59f
Author: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Date:   Sun Jan 29 17:48:54 2012 +0100

    tmpnam, tempnam are obsolete in SUSV4
    
    Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

commit fba639dcdcc2f3fede71e8bcd1a1a525a7f57d61
Author: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Date:   Sun Jan 29 15:46:50 2012 +0100

    handle signal-OBXSI.SUSv4.syms
    
    A couple of sig functions are obsolete in SUSv4.
    
    Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>

Рад что оно развивается. Полезная штука. Как-то игрался с ней немного, очень порадовала.

КЭП намекает: собрать stage1/stage2 самому или воспользоваться готовым stage3-uclibc(проект ведется ЕМНИП полуофициально каким-то испанцем или португальцем)

Где про это можно почитать? Можно ли конвертировать существующую систему? И насколько безгеморройно заюзать eglibc?

поставить Убунту и начать от неё отсекать всё лишнее, как скульптор

Лучше использовать debootstrap

Можно ли конвертировать существующую систему?

это не так просто, но реально. crossdev в помощь...

И насколько безгеморройно заюзать eglibc?

хз, не пробовал

Где про это можно почитать?

Про сам экспериментальный стейдж - http://judepereira.com/blog/x86-uclibc-stages/

это вообще как?

Конфигурацией. Выбираешь в утилите конфигурации, что тебе из библиотеки необходимо. Остальное выкидываешь.

В итоге компилируется библиотека только с теми возможностями, фичами, которые ты используешь.

Так же конфигурируется сам buildroot. В итоге от линюкса можно оставить самую малость, что бы своя программа крутилась.

это не так просто, но реально. crossdev в помощь...

Мда... Дебиан проще. :)

и ничего в нём не было, кроме среды разработки для лиспа и браузера по фидонету.

ВЕКТОРНОГО браузера, прошу заметить.

Хотя удобства голого деда никакой лор не заменит.

А вообще, самый классный проект для реального использования uClibc на десктопах был Deli. Жаль, что помер. Он действительно был заменой всяких windows95 на старых системах.

Так же, как и eglibc - параметрами сборки.

1. Не соберется

2. Если бы собралась, стала бы медленнее. Количество раз - хз. Но памяти ела бы немного меньше.

Проэкт развивается - и это радует.

будет медленней, компактный размер достигается в том числе из-за отказа от оптимизаций

Не всё так просто: код меньшего размера имеет больше шансов целиком уместиться в процессорном кэше. Так что, без тестов сказать наверняка нельзя.

А как в вашем Gentoo glibc поменять на что-нибудь другое?

канонiчный способ — курить USE-флаги в профилях : elibc_glibc kernel_linux multilib userland_GNU ( — это флаги в профиле, просто так они не видны). То есть, запилить свой профиль по аналогии с Gentoo/FreeBSD, а лучше, Gentoo/Prefix. В котором сделать *НОВЫЙ* USE-флаг, говорящий с какой libc собирать, потому что какой-то конкретный софт вполне может требовать именно GNU glibc.

Правда, потом выяснится, что другой libc — это только начало, потому что затем нужно собирать весь новый тулчейн с новым libc, а он может и не собраться в общем случае (если libc не glibc и/или ядро не Linux). И нужны велосипеды над bashrc, наподобие тех, что делались для сборки конкретного пакета конкретным компилятором (gcc/icc/clang).

Проще всего это (сборка тулчейна целиком) делается через crosstools.

Когда делается например, emerge system, при этом в профиле включается невидимый use-флаг, который юзается в зависимостях, описывающих system (в разных ядрах, linux/freebsd/gentoo prefix — они разные, например, если +kernel_linux -kernel_bsd, то +elibc_glibc -elibc_freebsdlibc и +userland_GNU, если -kernel_linux +kernel_bsd то -elibc_glibc +elibc_bsdlibc -userland_GNU (или +-, ведь Фря неканонiчная GPL/BSD only, можно mixmatch).

То есть, если для kernel_linux зависимости system идут от gcc, glibc,coreutils,m4, perl (autotools), то для kernel_bsd зависимости теоретически можно сделать от clang, libc++, и т.п., а для какой-нибудь kernel_haiku — тоже, прикрутить разные toolchain.

Практически, в случае с portage нужно описывать кучу этих скучных вспомогательных USE-флагов в профилях, а профит от «корректной» писанины через профили по сравнению с вариантом со сборкой через кросстулзы невелик, если целевая система — тоже линукс ядро. Для paludis уже веселее, у него профили попроще чем у portage, фактически (оверлей=репозиторий)+/etc/paludis/bashrc=профиль.

Где про это можно почитать?

http://www.gentoo.org/proj/en/base/embedded/cross-development.xml http://en.gentoo-wiki.com/wiki/Crossdev http://ru.gentoo-wiki.com/wiki/HOWTO_Gentoo_на_КПК http://elinux.org/Toolchains#Crossdev_.28Gentoo.29

Можно ли конвертировать существующую систему?

нет, потребуется пересборка кросстулчейном нужной целевой системы. Конвертировать = просто, если целевая система — тоже линукс, и софт не нужно портировать. Или, это может быть довольно сложно, если целевая система — mingw, freebsd, gentoo prefix и нужно менять структуру зависимостей пакетов.

И насколько безгеморройно заюзать eglibc?

eglibc и newlib довольно хорошо совместимы с glibc. Вот dietlibc например, уже куда менее, не говоря уже о всяких mingw/freebsd/haiku. Но полной гарантии, как понимаешь нет. Если софт вообще собрался с другой либц, есть шансы, но нужно полноценно тестировать.

есть dietlinux, сильно быстрее за счёт dietlibc. с другой стороны именно поэтому с dietlibc собирается 3.5 программы вместо system и тулчейна. с uClibc должно быть посовместимее. во сколько раз быстрее — нужно делать полноценные тесты.

А как в вашем Gentoo glibc поменять на что-нибудь другое?

Звучит как «А как в вашем Linux поменять GCC на Clang, glibc на uClibc, binutils на llc, ну и до кучи, ядро Linux на что-то другое». Краткий ответ — никак, потому что потом весь остальной софт, начиная с system (либц,тулчейн, аутотулзы для сборки, шелл и т.п.) нужно заменять на кросскомпилированные в новой целевой системе, а он (софт) может и не собраться.

Бида-бида в том, что зачастую (g|uc)libc гвоздями прикручен к линукс ядру, а уже линукс-софт — гвоздями прикручен к glibc (в отличие от православного юникс-софта, прикрученного к posix libc). Поэтому для полноценного портирования например линукс софта в хайку (обкоцанный bsd по сути) нужно либо хакать до посинения сам софт, переписывая линуксизмы на что-то мобильное, либо хакать до посинения *libc, портируя его на хайку libc, а уже на этот *libc ориентировать сам портируемый софт. Правда, надо сказать, что uclibc чуть менее, чем glibc прикручен. Потому что сборка glibc сильно завязана на сборку именно gcc-ой, во первых, а во-вторых, именно из-под Linux (см. ключ в конфигах =путь к хедерам /usr/src/linux, из которых перлом, седом и авк выдираются коды сисколлов и строятся врапперы в либц к сисколлам). В glibc это делается факин аутолулзовой магией, а в uclibc почти приличным скриптом, поэтому портировать uclibc на другое ядро проще. А идеальный либц был бы вообще не завязан на систему сборки и компилятор. С другой стороны именно для линукса смысла в этом нету вообще, так как и в ядре и в glibc полно gcc-измов.

Вообще, что такое ABI и бинарная совместимость? Это совместимость интерфейсов на разных уровнях: 1) сисколлы ядра-«внешний» posix-совместимый интерфейс libc 2) либц, собранная конкретным компилятором, и библиотеки нижнего уровня, собранные этим компилятором (сalling conventions) 3) версии других библиотек или прикладного софта и библиотек нижнего уровня (динамический линкер, ld.so в ядре и в /bin/ld.so)

Когда ABI ломается, ломается где-то на границе этих трёх. При этом есть лишняя зависимость от конкретной версии конпелятора. Поэтому нельзя в общем случае заменить один либц на другой, один конпелятор на другой, один механизм динамической линковки на другой, (К.О.: одно ядро ОС на другое), простой заменой одной части, чтобы всё в целом продолжало работать — требуется пересборка мира (а на самом деле, пересборка той оставшейся части целевой системы, в соответствии с которой должен быть новый ABI).

Сравни например без линукса, своё ядрышко http://wiki.osdev.org/Barebones http://wiki.osdev.org/Category:Bare_bones_tutorials c процессом через crossdev в Gentoo http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml

+ на базе LLVM есть ELLCC http://ellcc.org/blog/?p=78 http://www.opennet.ru/opennews/art.shtml?num=32793

поэтому в генте по сути появляется не один линукс ABI, а несколько вот этих ABI описываемых IUSE: amd64 kernel_linux elibc_glibc GNU_userland. Вот это и есть линукс ABI, и то — не весь: ещё нужно дополнить версией gcc, glibc, binutils и линукс-ядра, с которыми всё собиралось, чтобы более-менее полностью описать конфигурацию «линукс ABI». Потому что в новом gcc может измениться layout бинарников, в новых binutils — динамический линкер и поломаться ABI, а glibc вообще нужно рассматривать совместно как SAFE пары glibc-linux_kernel. Добавь сюда ещё USE-флаги, влияющие на сборку system пакетов и ты получишь примерное представление о «линукс ABI».

Ещё в Gentoo относительно недавно есть crosstools-ng: https://bugs.gentoo.org/show_bug.cgi?id=258396

Оно фичастее crossdev, удобнее и т.п.

или http://wiki.osdev.org/LLVM_Cross-Compiler

Опциями ./configure