Re[2]: [devel] [BUG?] devel/RPMS/i586/

[Alexander Bokovoy <ab@avilink.net>]

Hello Dmitry,

Thursday, November 02, 2000, 6:17:02 PM, you wrote:
>> > Каких махинаций?
>> rpm2cpio rpm-3.0.6-ipl?mdk.i586.rpm >rpm.cpio
>> rpm2cpio rpm-3.0.6-ipl4mdk.src.rpm >rpm.src.cpio
>> Теперь берем из rpm.cpio /bin/rpm, из rpm.src.cpio вытягиваем исходники и затем
>>  rpm -ba rpm.spec
>> проблема была в том, что несколько версий бинарного rpm сразу не заработали и только
>> ipl3mdk дал нужный результат.
>> Вообщем, потом пересобраным rpm-мом собирал его же на обновленном компиляторе и
>> glibc. После этого все ожило.
> Brr!
Собственно говоря, приведенное ниже объяснение причины прекрасно
укладывается в эту "брр-схему", поскольку все статическое, собранное
на photo, валится на k6.

>> > Замечу, что к gcc претензий нет: rpm собирался с gcc-2.96, а ядро - c
>> > gcc-2.95.3.
>> glibc?
> Ой!
> Ну конечно, как же я сразу не догадался.
> Все статически слинкованные программы (это как раз /boot/vmlinuz* и
> /bin/rpm) включают код для i686 из glibc).
> Придется на photo все разделяемые библиотеки ставить в варианте, собранном
> для i586 (ибо rpm включает в себя куски кода не только из glibc).
> Жаль...
Может быть можно сделать более цивилизованный вариант с "зажимом"
кэшей библиотек в нужные позиции при сборке под разные target?  Просто
хранить несколько деревьев библиотек и при сборке автоматически
переписывать ldconfig под этот вариант, можно в chrootted environment.
Понятно, что работа частично должна будет идти под root-ом, но тогда
хоть можно будет и photo полноценно использовать, и оптимизацией не
поступаться.

-- 
Best regards,
 Alexander                            mailto:ab@avilink.net


_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel