Upgrade glibc и gtk

[sfs]

А может еще глобальней : взять arch base и надеть на наше ядро и initrd +pfs. Нужное перекомпилить с нашими ключами. Исходники , AUR и т.п. хорошо ложится в концепцию. Arch пакеты типа pet только xz. Перепереть в pfs одним скриптом. Может и pacman удастся приспособить.
А потом апдейтить раз в год\полгода обычной процедурой - а не как у нас в этой ветке - "метод научного тыка" + "битва за урожай"
Репа под pacman делается на dropbox и т.п. Т.е все проблемы решаем разом и цивилизованно. Live направление в арче никакое. Есть перспективы взаимовыгодности...
...Все это про PuppyRus3. Надо ли все из этой ветки пихать в 21 - не уверен...

[andy-voit]

Слишком глобальные задачи пока никто не потянет.

[sfs]

Мне как раз кажется так может получиться легче, а не сложнее

Что-то мы отвлеклись....
Собрал на базе своего рецепта все нужные либы и gcc472 . Пока не перезагрузил ПК - работало.
Итог: похоже оттолкнувшись от gcc471 можно собрать, но не мне. Я тут и так попробовал сильно "выше головы прыгнуть"  Надо ключи смотреть.

До перезагруза пробовал уже с gcc472 собрать glibc217. Это - вообще никак :

Код

fscanf.o.dt -MT /root/.Trash/glibc-build/stdio-common/isoc99_fscanf.o
../sysdeps/unix/sysv/linux/renameat.c: В функции «renameat»:
../sysdeps/unix/sysv/linux/renameat.c:184:1: ошибка: «__NR_rename» undeclared (first use in this function)
../sysdeps/unix/sysv/linux/renameat.c:184:1: замечание: each undeclared identifier is reported only once for eac
make[2]: *** [/root/.Trash/glibc-build/stdio-common/renameat.o] Ошибка 1
make[2]: *** Ожидание завершения заданий...
make[2]: Выход из каталога `/root/.Trash/glibc-2.17/stdio-common'
make[1]: *** [stdio-common/subdir_lib] Ошибка 2
make[1]: Выход из каталога `/root/.Trash/glibc-2.17'
make: *** [all] Ошибка 2

Про компиляцию gclibc нагуглил http://clck.ru/6JDXg http://clck.ru/6JDXu

[Pro]

А может еще глобальней : взять arch base и надеть на наше ядро и initrd +pfs. Нужное перекомпилить с нашими ключами. Исходники , AUR и т.п. хорошо ложится в концепцию. Arch пакеты типа pet только xz. Перепереть в pfs одним скриптом. Может и pacman удастся приспособить.
А потом апдейтить раз в год\полгода обычной процедурой - а не как у нас в этой ветке - "метод научного тыка" + "битва за урожай"

проблем не будет до тех пор пока не возникнет конфликта "Какого хрена они это так собрали" и будет сделан свой пакет, и будет еще и еще пакет, в итоге будет как щас.
И эта, раз в полгода весь репозитарий Arch перегонять в pfs - грустно. Вот когда Arch перейдет на pfs пакеты - обсудим.

[andy-voit]

А какого же хрена на него ссылается старая libgmp.so.3 в старом devx?
незнаю но судя по содержимому каталога engines, к gcc это не относится, возможно локальная версия какого то пакета.

Весь этот каталог, как и многое другое, является частью пакета sceleton. Который сам является сборником каких то пакетов.

Еще в базе почему то находится пакет gcc_lib 4.3.4-1.pfs Кроме того, что это относится чисто к компилятору, а следовательно к devx - это еще и один "хвостик" старого компилятора.

[Pro]

Еще в базе почему то находится пакет gcc_lib 4.3.4-1.pfs Кроме того, что это относится чисто к компилятору, а следовательно к devx - это еще и один "хвостик" старого компилятора.

вот ненадо делать преждевременных выводов, да еще так категорично. Библиотеки компилятора размещаются не только в devx, но и используются программами.
Упомянутый вами пакет gcc_lib 4.3.4-1.pfs кроме всего прочего содержит в себе libstdc++ попробуйте снести ее, будет весело. К слову сказать из представленного пакета компилятора, я также сделал gcc_lib-4.7.2.pfs с нужным содержимым.

[Pro]

Весь этот каталог, как и многое другое, является частью пакета sceleton. Который сам является сборником каких то пакетов.

не каких то, а тех же из которых делается оригинальный Puppy. Думаю если поискать, то gcc_lib 4.3.4-1 найдется как pet пакет в репозитари оригинального Puppy.

Гугль по /usr/lib/engines показал что это у нас от пакета openssl хвостик. Проверю, если пакет есть то будет убрано из 0rootfs

[sfs]

ibstdc++ попробуйте снести ее, будет весело.

Пробовал. Сносить нельзя

[andy-voit]

ibstdc++ попробуйте снести ее, будет весело.

Пробовал. Сносить нельзя

Я имел ввиду не полный снос, а замену на более свежие версии и упорядочивание. Сейчас в дистрибутиве присутствуют одновременно libstdc++ пятой и шестой версий . Причем при обновлении gcc до версии 4.7.2 появится еще одна библиотека шестой версии. Я лично об этом. Впрочем, как я понял процесс идет и дай бог.

[Pro]

Вполне естественно при обновлени gcc_lib 4.3.4-1.pfs будет убран и поставлен gcc_lib 4.7.2.pfs соответственно libstdc++ шестой версии уберется.
libstdc++ 5 версии нужна для совместимости программ мы ее специально ставили чтобы работали программы из репозитария оригинального Puppy, убираться не будет, будет лежать еще долго (минимум год-два).

[Pro]

как убирается проблема с stddef.h ?
я вроде все почистил от старого.

[andy-voit]

А где такая проблема возникает?

[Pro]

дык была тут на 7 странице, а у меня возникла в обновленном devx и при попытке компиляции

судя по gmp.h он хочет stddef.h из пакета gсс - а нету.

В исходниках gcc подобное есть в каталоге gcc/ginclude/ может стоит оттуда все файлики положить в /usr/include/ ?

[sfs]

как убирается проблема с stddef.h ?

Последовательной пересборкой
binutils-2.22.52.0.2.pfs
gmp-5.0.5-i486.pfs (лучше последний)
gmp_DEV-5.0.5-i486.pfs
libmpc-0.8.2.pfs
libX11-1.5.0-sl-s02.pfs
mpfr-3.1.0.pfs
и только потом уже сборкой gcc
иначе gcc собирается но не работает:  stddef.h

[andy-voit]

У меня компилятор работает, такой проблемы нет. Вышеупомянутые пересобраны, кроме libX11, и помещены в мой неофициальный devx, включая DEV файлы. Проблемы не возникает.