Привет, Semen!
27 Oct 23 08:15, ты писал(а) мне:
SP>>> Я сегодня утром наконец-то смигрировал ноду на 64-битный линух.
SP>>> Скока лет собирался :) И да, husky там остался 1.4. Пришлось
SP>>> научиться делать 32-битную сборку в 64-битной multilib системе
SP>>> :) (там много чего и под 64 бита собирается, но вроде как есть
SP>>> мнение, что работает оно неправильно, базы портит).
VA>> Ух ты. Откуда дровишки?
SP> Да откуда-то из RU.HUSKY вроде. Я уж и не вспомню.
VA>> $ file /usr/bin/gedlnx
SP> Ну дык с ним всё норм, по крайней мере со свежим.
VA>> $ file /usr/bin/hpt
SP> А вот тут ты версию не указал :)
SP> Я может не очень точно выразился, проблемы с husky-1.4 вроде как
SP> только, про проблемы с другим фидософтом (из того что я использую) я
SP> не слышал.
Вот оно чё. Значит, в 1.9 это фиксили. Подозреваю, что это связано со способом
"десериализации", когда из файла вычитывают блоб, а потом делают
reinterpret_cast. При этом 32 и 64 битные системы имеют разные размеры тех же
типов. Я уже молчую про Little/Big Endian. В хасках, кстати, в документации,
есть целый раздел по этому поводу.
VA>> /usr/bin/hpt: ELF 64-bit LSB pie executable, x86-64, version 1
VA>> (SYSV), Полет нормальный больше года.
SP> Ну дык если 1.9 то и не удивительно...
Будем знать, что на 1.4 лучше не переходить. :)
SP>>> Может когда-нибудь на 1.9 таки перееду, но всё ещё есть моменты,
SP>>> которые пока меня останавливают от этого, не только
SP>>> необходимость конфиги мигрировать...
VA>> Например? Конфиги я переделал за один вечер. Там ничего сложного.
SP> Ну помимо "лень и некогда" есть ещё bsopack, который сейчас не
SP> собирается через huskymak.cfg + общий Makefile, но у меня зачем-то
SP> используется на ноде, уж и не помню зачем (настроил дофига лет назад
SP> шоб работало как мне надо, и уже успел забыть чё как :) ) По
SP> инструкции из самого bsopack тоже не собирается.
Там много инструкций устарело. Мне тоже пришлось разбираться, что ж так сильно
поменялось. Вот, кстати, раз ты уже туда влез, может и инструкции подправишь,
где они некорректные сейчас? Или, хотя бы напиши в эху, какие из них
некоректные. Можно в гитхабе еще создать Issue, чтобы не забыли.
SP> Ну и не дотестил окончательно я ещё свой ebuild для current husky.
SP> Вот буквально вчера там вмержили нужные мне правки чтобы доки не
SP> гзипались при сборке, надо снова ebuild править под них... В общем
SP> current это вам не stable :) Но это уже лучше в RU.HUSKY а не в
SP> RU.GOLDED...
Согласен.
SP>>> Golded благо одинаково прекрасно работает и на 32 и на 64 битах
SP>>> :)
VA>> Работает. Но зачем? :)
SP> А как жить без голдеда? :)
Я имел ввиду, зачем на 64 битной системе 32 битный дед.
/me записал себе в блокнотик, что нужно учиться выражать свои мысли понятнее.
:)
SP> Повторюсь, я не совсем правильно выразился. На 32 битах прекрасно
SP> работает 32-битный голдед, на 64 битах прекрасно работает 64-битный
SP> голдед, да и 32-битный наверное тоже будет прекрасно работать на 64
SP> битах, не проверял :)
Будет, что ж ему сделается? :)
SP> Цель была именно 32-битные husky-1.4 собрать.
SP>>> Ух ты, вот только сейчас заметил CPU UNKNOWN. А на 32-битном он
SP>>> лучше детектился... Беру свои слова обратно про одинаково
SP>>> хорошесть работы 32 и 64 битного голдеда :)
VA>> Все можно поправить. Было бы желание.
SP> Да это понятно... Понять бы сначала, чего авторы того ассемблерного
SP> кода хотели добиться. Может всё можно из /proc/cpuinfo вытащить
SP> безвозмездно вместо этого...
Можно вставить отдельный кусок кода для линуксов, чтобы именно так и делать. Ну
или разобраться, почему асм в твоем случае не детектит. Это даже лучше, ведь не
все на линуксе работают.
SP> Чёт меня этот CPU UNKNOWN прям заинтриговал. Есть желание
SP> поразбираться :)
Давай! Интересно посмотреть, в чем же причина.
Best regards,
Vitaliy Aksyonov.
... Истина где-то здесь, где собака порылась.
