В состав веток "unstable" и "experimental" Debian GNU/Linux интегрирована (http://blog.aurel32.net/?p=47) поддержка системной библиотеки Embedded GLIBC (http://www.eglibc.org) (EGLIBC). В будущем разработчики планируют полностью заменить на eglibc стандартную библиотеку GNU C Library (GLIBC (http://www.gnu.org/software/libc/)).
Библиотека eglibc разработана с целью использования на встраиваемых системах и отличается значительно более низкими системными требованиями, возможностью гибкой настройки компонентов, улучшенной поддержкой кросс-компиляции и кросс-тестирования. При этом библиотека полностью совместима с glibc как на бинарном уровне, так и на уровне исходных текстов. Из известных проектов использующих eglibc можно отметить OpenWrt (http://www.openwrt.org/).
Из достоинств библиотеки разработчики Debian отметили:
- Более дружелюбное и открытое комьюнити разработчиков (glibc почти единолично развивает Red Hat);
- Наличие стабильной ветки, в которую включаются исправл...URL: http://blog.aurel32.net/?p=47
Новость: http://www.opennet.me/opennews/art.shtml?num=21615
любопытно чем это кончится
Новость стоило сформулировать так: редхатофобы захватили власть в дебиановском комьюнити и решили, что им нужен свой glibc, с блекджеком и шлюхами.Думаю, следующий шаг - полный отказ от поддержки ядра linux ;)
Ты будешь смеяться, но использование ядра Linux это и есть временная мера в системе GNU. До тех пор, пока не будет готово ядро Hurd ;)
Ну когда же уже оно будет готово?
Уже вон и L4 наподходе к стабильности а Hurd-a все нету и нету...
>Уже вон и L4 наподходе к стабильности а Hurd-a все нету и нету...Наверное когда я буду старым и выйду на пенсию - как раз поспеют, и то и другое :).ИМХО нету их поскольку реальная востребованность всего этого - невелика.Как бы ни было досадно эстетам.
Увы и ах, лично мне очень жаль, но выглядит будто бы на Hurd (точнее Mach microkernel) давно и жирно забили все (включая сообщество) кроме Apple (как известо в основе MacOS X лежит BSD окружение и Mach микроядро).Ядро Linux постигла судьба архитекруры x86 - слишком много вложено в него монстрами индустрии, и слишком хорошо к нему уже все адаптировались чтобы взять и отправить его на свалку legacy технологий.
Важная поправка - если оно будет лучше и затраты будут целесообразны переменам.На данном этапе, когда Linux уже давно и неплохо работает много где, а Hurd - всё только в мечтах, речь о том, что "вот-вот, уже-уже выйдёт Hurd и Linux сразу скинут" - наивны.
Выбрасывать развитую экосистему, которая в некоторых областях уже де-факто стандарт ради какой-то там идеологии GNU или Ъ-шности Hurd никто не будет в здравом уме. Да и в нездравом тоже
советую почитать ссылки на багзилу -- дреппер ведет себя довольно странно
Вовсе нет. Это его типичная манера общения :)
не HURDом единым:) а шлюхи и блекджек это ближе:)
не хочу вызвать религиозную войну, но, все таки, своя рубашка к телу то ближе..а ее отсутствме предпологает способы заработка на нее.так что, realtime приносить деньги будет, а linux desktop.
ЗЫ: основные десктопы-дебиан, редхат, убунту(простимягосподи),у мандривы даж книжку выиграл..
как бы джаст фо фан не взывал бойцов на борьбу, но сочетание сервер(корпорейт)+десктоп(канешн корпорейт+гейм+спец(CAD,ERP,документооборот)) будет на уровне джаст фо фаном.причем с рейтингом ниже лего
А что в этом плохого?
на сколько я понимаю это потенциальные проблемы совместимости.
Пока что их нет.
Точно... Программы, собранные для eglibc, не будут работать в системе с glibc. И наоборот. Даже сейчас не все программы, собранные для более ранних glibc, запускаются на системе с новой glibc. Справедливо по крайней мере для glibc 2.3.x 2.2.x Загрузчик начинает говорить, что не найден символ GLIBC_2 трали-вали (что-то похожее).В своё время пробовал заменить glibc на ulibc. Геморой. Куча программ не собирается или не запускается. Давно это было. Но думаю, что ситуация не изменилась. ulibc особо не развивается. Зато как кошки плодятся всякие новые klibc, eglibc. Для специализированного примения всякая годится. А так пока замены glibc не видно...
К тексте новости русским по белому написано, что у eglibc совместимость с glibc и бинарная, и на уровне сорцов.ulibc (это ведь Вы так uclibc обозвали?) не имеет ни такой совместимости (полной), ни цели ее заиметь. Не говоря уж об узкоспециальной klibc.
Ну если все стандарты, от K&R до C++0x будут, тогда пофиг.
>Ну если все стандарты, от K&R до C++0x будут, тогда пофиг.Возможно неправ, но все же проясните, при чем тут стандарты на плюсы и сишная библиотека? =\
А libstdc++ где живёт?Мне-то вапще пох... я С++ незнаю, и знать не хочу.
Давеча, упалпадстол, после того, как g++ меня отшило со словами
error: ISO C++ forbids initialization of member 'a'
error: ISO C++ forbids in-class initialization of non-const static member 'a'
error: ISO C++ forbids initialization of member 'b'
error: making 'b' static
error: ISO C++ forbids in-class initialization of non-const static member 'b
на кодtypedef struct { int a = 0; int b = 0; } x;
:)
> А libstdc++ где живёт?GCC.
> typedef struct { int a = 0; int b = 0; } x;
Неудивительно, что компилятор это не понял. Я вот тоже не могу понять, что бы это значило...
Чушь какая-то. typedef задает синоним типа. Я даже не могу предположить, что ты хотел сделать :)
Да всё нормально. Так можно объявлять типы (кстати, такая манера объявления пришла в С++ из C).
>Чушь какая-то. typedef задает синоним типа. Я даже не могу предположить, что
>ты хотел сделать :)А что же тогда пишешь, если не фкуривашь...
Смысла слеующая.
Когда, в нужном месте, объявлю новую переменную типа (struct x), то она будет абнулёвана :)Cинонимы:
struct SuperStuct { int a = 0; int b = 0; };
typedef SuperStuct х;
-----------------------------------------------
struct { int a = 0; int b = 0; } SuperStuct;
typedef SuperStuct х;
-----------------------------------------------struct SuperStuct { int a; int b; } = {0, 0};
typedef SuperStuct х;
-----------------------------------------------struct SuperStuct { int a; int b; };
myfunc() {
struct x a = {0, 0};
struct x a = {{0}};
}Собственно причёсывал код, после "Писателей" - любителей memset();
int a[10];
memset(a, 0, sizeof(a); :)Наверно тяжело было, просто
int a[10] = {0};
Таже фигня со структурами...
int a[10] = {0};странно... а если написать int a[10] = {5}; то всё пятёрками инициализируется или только первый элемент массива? привет от любителей memset()!
>int a[10] = {0};
>
>странно... а если написать int a[10] = {5}; то всё пятёрками инициализируется
>или только первый элемент массива? привет от любителей memset()!Не, так только первый, он же нулевой - int a[0] = 5, остальные нули :)
вообщем, int a[10] = {0}; полная чушь. советую поставить на место memset() там где его поставили "писатели" любители memset() ну или на худой конец написать не {0} а {0,0,0,0,0,0,0,0,0,0}
>вообщем, int a[10] = {0}; полная чушь. советую поставить на место memset()
>там где его поставили "писатели" любители memset() ну или на худой
>конец написать не {0} а {0,0,0,0,0,0,0,0,0,0}int A(){
int a[10] = {0};
}int B() {
int b[10];
memset(b, 0, 10);
}
#gcc -S test.c
# cat test.sA:
.LFB0:
...
movq $0, -48(%rbp)
movq $0, -40(%rbp)
movq $0, -32(%rbp)
movq $0, -24(%rbp)
movq $0, -16(%rbp)
leave
ret
...
B:
.LFB1:
...
subq $48, %rsp
leaq -48(%rbp), %rax
movl $10, %edx
movl $0, %esi
movq %rax, %rdi
call memset
leave
ret
..
Ну и накуя мне лишние SUB и LEA, и особенно CALL ??? - Вот так ВИДУЗЯТНИКИ и пишут!!!
спор окончен. вы, товарищ, абсолютно неконструктивно брыжжете по сторонам слюной при том не понимая смысла элементарных конструкций языка С.
>спор окончен.Угу, упал и от жался...
> вы, товарищ, абсолютно неконструктивно брыжжете по сторонам слюной при томне конструктивно брызжете - пишется.
>не понимая смысла элементарных конструкций языка С.Где вы тут конструкции нашли...
Я ему про лишние функции и элементарную оптимизацию, он про возвышенные формы...
Начнём с того, что в memset надо было указать не "10", а "sizeof(int)*10". А продолжим тем, что даже с "-O" (даже без "-O2") обе функции выглядят так:A:
.LFB24:
movq $0, -56(%rsp)
movq $0, -48(%rsp)
movq $0, -40(%rsp)
movq $0, -32(%rsp)
movq $0, -24(%rsp)
retB:
.LFB25:
movq $0, -56(%rsp)
movq $0, -48(%rsp)
movq $0, -40(%rsp)
movq $0, -32(%rsp)
movq $0, -24(%rsp)
ret
И поверьте, если вы компилируете без флагов оптимизации (единственный случай, где ваши доводы актуальны), то то, что вы предлагаете - лишь экономия на спичках.
Если кто-то хочет убедиться лично, пусть сделает:
cat | gcc -S -o - -x c -O2 -#include <string.h>
int A(){
volatile int a[10] = {0};
}int B() {
volatile int b[10];
memset(b, 0, 40);
}^D
Естественно компилятор выдаст ошибки. :)
Кто тебе сказал, что инициализировать члены класса (структуры) можно прямо в месте объявления? Хотя можно, но они должны быть static и при этом const и ещё иметь тип целого числа (long, int, short, char). Почитай стандарт. В новой версии С++ будет возможна инициализация в месте объявления членов класса.Смешно, ты пишешь код неправильно и обижаешься, что компилятор тебя не понимает.
Я тоже бы хотел, например, в языке D иметь возможность множественного наследования, но её там нет. Так что теперь, сопли с сахаром по этому поводу лить и говорить что этот язык дерьмо? Не смеши народ.
>Смешно, ты пишешь код неправильно и обижаешься, что компилятор тебя не понимает.
> Не смеши народ.Зачем нужон язык который деградировал относительно своего предка.
Если я в уме считаю тройные интегралы, это не значит, что я забыл деление столбиком, счёты, и Феликс-М...
>при чем тут стандарты на плюсы и сишная библиотека? =\Стандарт предусматривает наличие определённых функций, большая часть из которых живёт в glibc. Ну и должна жить в eglibc, если собираются бескровно на неё мигрировать. Это относится не только к C, но и к C++, хотя там доля функций, живущих в glibc, меньше.
т.е. флеш, опера, неро & etc proprietary products под дебианом жить не будут.. будем мигрировать на шапку, или на что-нибудь другое тогда)
>т.е. флеш, опера, неро & etc proprietary products под дебианом жить не
>будут.. будем мигрировать на шапку, или на что-нибудь другое тогда)Блин, ну написано же - бинарная совместимость, тоесть будут
Значит ли сие что это будет на убунте?
Конечно, бубунта же все пакеты из дебиана берет
насколько я понял, мужики из glibc просто предложили не городить огород и вынести код для embedded devices в отдельную библу, вот и отпочковались.
Коллеги, а на сайт eglibc никто сходить не пробовал? Суть проекта eglibc состоит в том, чтобы взять сорцы glibc, подправить make скрипты так, чтобы без надобности не собиралось все лишнее (типа NIS) и не возникало ошибок при кросс-компиляции и все! Т.е. eglibc по сути и есть glibc, только по-другому собранное!
то-то я всё думал, чтобы это значило:
>При этом библиотека полностью совместима с glibc ... на уровне исходных текстов.? :-D
А минусы по сравнению с glibc у неё есть?
Судя по посту выше, в ней не будет NIS
Репозиторий EGlibC выдаёт какую-то позорную ошибку:
svn: In directory 'eglibc-2.10\ports\sysdeps\m88k\m88100'
svn: Can't open file 'eglibc-2.10\ports\sysdeps\m88k\m88100\.svn\tmp\text-base\add_n.s.svn-base': The system cannot find the file
specified.