glibc 2.3

Вот это меня добило окончательно:
Contents of the LC_* and LANG environment variables
in the CEN style are not recognized anymore.
It never was used. Change by Ulrich Drepper.

А как быть с программами, которые иначе не могут?
Их о-о-й сколько...

А что такое CEN style??? Не будут же они просто так ломать локаль? Хотя от КрасноШапки можно ожидать любой гадости :(

CEN syntax: language[_territory][+audience][+special][,[sponsor][_revision]]

Вы часто так локаль задаёте?

Как говорится "могло быть и хуже..."

Ну я часто задаю: LANG=en_US или LANG=ru . Вполне соответствует CEN syntax. Что, это больше не будет работать и всегда надо будет бить LANG=ru_RU.koi8r?

hvv
Ну почему же - можно ru_RU.CP1251 или ru_RU.UTF8

:)))))

Теперь что можно ее задавать только как language_TERRITORY.CODEPAGE ? гым .....

AffreuxChien: :)))))

Вот только что закончил перевод системы на GLIBC 2.3. Что можно сказать ? В целом неплохо. Есть некоторые проблемы с локалью(ввод и вывод в порядке, но интерфейс некоторых программ не на русском(МС к примеру)). Кстати до глибс 2.3 они не собирались гсс3(ну иногда собирались но наотрез отказывались работать или жутко тормозили). Наблюдается некоторое ускорение программ(не очень большое). bash при загрузке выдавал segfault, пришлось его пересобрать. А так вроде все в порядке.

А кто знает, реально ли это чудо собрать под спарк под соляркой 2.4? Очень поиметь хочется, а 2.2 не собиралось :(

2Galahad (*) (2002-10-04 15:18:50.629):

> Вот только что закончил перевод системы на GLIBC 2.3.
> Наблюдается некоторое ускорение программ(не очень большое).
> bash при загрузке выдавал segfault, пришлось его пересобрать.
> А так вроде все в порядке.

IMHO при смене такой штуки как GLIBC надо вообще всё пересобрать
по-хорошему. Разве не так? bash bash'ем, но есть вещи, которые
сразу и не заметишь :-/

Ну почему же так сразу и всё? Сказано же что она бинарно совместима с предыдущими glibc. Я уже разобрался с этой проблемой: сегфолтятся только статически собранные программы, остальные нет. Сейчас я этим и занимаюсь.

А вот кто мне поможет справится с такой проблемой:
=== cut ===
gcc -B/usr/ -nostdlib -nostartfiles -o iconvconfig -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-z,combreloc ../csu/crt1.o ../csu/crti.o `gcc -B/usr/ --print-file-name=crtbegin.o` iconvconfig.o strtab.o xmalloc.o -Wl,-rpath-link=..;../math;../elf;../dlfcn;../nss;../nis;../rt;../resolv;../cryp t;../linuxthreads ../libc.so.6 ../libc-nonshared.a -lgcc `gcc -B/usr/ --print-file-name=crtend.o` ../csu/crtn.o
../libc.so.69.data=0xb4c0; multiple definition of `--ctype-toupper2GLIBC-2.0'../libc.so.698IND8=0x00; multiple definition of `--ctype32-toupper2GLIBC-2.2'../libc.so.69.data=0xb540; first defined here../libc.so.69.data=0xb500; multiple definition of `--ctype32-tolower2GLIBC-2.2'../libc.so.69.data=0xb400; multiple definition of `--ctype-b2GLIBC-2.0'../libc.so.698IND8=0x00; multiple definition of `--ctype-tolower2GLIBC-2.0'../libc.so.69.data=0xb480; first defined here../libc.so.69.data=0xb440; multiple definition of `--ctype32-b2GLIBC-2.0'
=== cut ===
при линковке iconv. =(
Все остальное до этого ок. Ума не приложу что ему надо. Понять-то понимаю что у него двойное определение переменных в бибилотеке, а как это пофиксить не знаю. =(
gcc 3.2, old glibc 2.2.5

> Я уже разобрался с этой проблемой: сегфолтятся только статически собранные программы

Если разобрался, то скажи, как такое вообще может быть? Статически собранная программа по идее абсолютно самостоятельна по отношению к внешним динамическим библиотекам. Как смена glibc могла затронуть
статически слинкованные программы? Ну очень интересно.

У меня возникла проблема: После того, как было собрана библиотека libc.so.6, процесс компиляции прекратился и выдано сообщение: make: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by libc.so.6) Любая другая программа выдает подобное сообщение, если ее запустить в в верхнем каталоге исходников ( у меня /usr/src/glibc-2.3).

Спасибо тому, кто подскажет путь решения этой проблемы.

В FAQ написано, что в компиляторе g++ версии 3.2 начинаются проблемы, кто нибудь столкнулся с этим?

Понятия не имею, но факт налицо. :o)

В догонку: у меня появились некоторые идей по этому поводу: изменились некие внешние данные(например локали хранятся по другому), а функции работы с ними остались старые(статическая компоновка) => очень даже возможен сегфаулт. Динамические же программы вызывают новые функции => все ок.

у меня не собралось.
<glibc-build-dir>/elf/ld-linux.so.2 сегфолтится и не дает компилировать дальше. Происходит на этапе компиляции sunrpc.

Ищу проблему... возможно трабла с binutils-2.13.90.0.4 (20020814).
Хотя в анонсе говорится, что именно с этой версией все оки-токи.
Сейчас попробую с gcc-3.3 (cvs).

А вот кто мне поможет справится с такой проблемой: === cut === [skipped] multiple definition of `--ctype32-b2GLIBC-2.0' === cut === при линковке iconv. =( Все остальное до этого ок. Ума не приложу что ему надо. Понять-то понимаю что у него двойное определение переменных в бибилотеке, а как это пофиксить не знаю. =( gcc 3.2, old glibc 2.2.5

Было аналогичное. Решилось установкой binutils 2.13.90.0.4.

фенк ю вери мач. А не подскажете где они есть именно 2.13.90.0.4 ? В releases лежит только 2.13... Или это cvs snaphot?

2nickg (*) (2002-10-05 16:47:28.151):
у тебя собралось? расскажи какое ядро и какой компилятор.

2anonymous (*) (2002-10-05 17:19:55.428):
брать с ftp://ftp.kernel.org/pub/linux/devel/binutils

проблема решилась установкой gcc 3.2.1 (cvs).
gcc 3.3 выдавал кучу всяких ошибок (т.е. еще очень не стабильная версия).

Скорее всего опять изменились файлы локализации (стали бинарно несовместимыми с предыдущей версией), которые статически связанные программы подхватывают извне. Такие проблемы именно со статическими бинарниками возникали при переходе между версиями внутри ветки 2.2.x.