Проблемы при сборке husky на *nix и их возможные решения

Alex Shuman написал(а) к All в Jul 22 04:34:02 по местному времени:

Это всё про husky-all-1.9-source-20220708.zip

Сегодня мы попробуем собрать husky на

FreeBSD 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:24:09 UTC 2021 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

и

Linux 5.15.0-1013-oracle #17~20.04.1-Ubuntu SMP Mon Jul 4 05:27:11 UTC 2022 x8664 x86_64 x8664 GNU/Linux

На обеих собирал себе в /home. Статическая сборка, с perl и hptzip.


Собственно, проблемы...

* Обе системы не любят CR/LF в .sh скриптах - было бы неплохо заменить просто на LF уже в дистрибутиве.

* Нет скриптов для офлайн сборки - initbuild и build.sh настойчиво хотят гитхаб. В документации INSTALL единственной альтернативой предлагается ручная сборка по "legacy makefiles" (но мне удалось собрать и без них). При этом, initbuild, в принципе, и при существующих исходниках (распакованных из архива) поправит вам конфиг для сборки, а вот build.sh будет ругаться на непустые каталоги и сборку не начнёт вообще.

* Без чтения build.sh не понятно, как именно можно собрать без скриптов - в различных INSTALL ничего не сказано про make / gmake depend

* В случае FreeBSD 13 предлагаемый компилятор clang не сработает - сборка остановится на неисправимой ошибке в одном из файлов исходников. Решение: использовать gcc/g++ . Решение пришлось искать в портах более старой версии.

* Сборка на FreeBSD у меня зависла при запуске pod2man, решение - не собирать то, что его требует (часть документации?).

* В общем мейкфайле сборки нет рецепта для hptutil. Или он больше не поддерживается? Отдельно собирать не пробовал.


...в общем, как же хорошо на винде, с уже собранными экзешниками, правда? :)

--- Neon BBS Line 2, 570-57-80, 20:30-06:30. [bbs.ncc.org.ua]

Michael Dukelsky написал(а) к Alex Shuman в Jul 22 20:21:08 по местному времени:

Привет, Alex!

31 Jul 22 04:34, Alex Shuman послал(а) письмо к All:

AS> Это всё про husky-all-1.9-source-20220708.zip

AS> Сегодня мы попробуем собрать husky на

AS> FreeBSD 13.0-RELEASE FreeBSD 13.0-RELEASE #0
AS> releng/13.0-n244733-ea31abc261f: Fri Apr 9 04:24:09 UTC 2021
AS> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
AS> amd64

AS> и

AS> Linux 5.15.0-1013-oracle #17~20.04.1-Ubuntu SMP Mon Jul 4 05:27:11 UTC
AS> 2022 x8664 x86_64 x8664 GNU/Linux

AS> На обеих собирал себе в /home. Статическая сборка, с perl и hptzip.

AS> Собственно, проблемы...

AS> * Обе системы не любят CR/LF в .sh скриптах - было бы неплохо заменить
AS> просто на LF уже в дистрибутиве.

Разумеется, в репозитории на гитхабе никаких CR нет. Удали свою копию репозитория, содержащую CR, выполни команду

git config --global core.autocrlf input

и после этого клонируй репозиторий по новой. Заодно почитай man git-config.

AS> * Нет скриптов для офлайн сборки - init_build и build.sh настойчиво
AS> хотят гитхаб. В документации INSTALL единственной альтернативой
AS> предлагается ручная сборка по "legacy makefiles" (но мне удалось
AS> собрать и без них).

Да, собирался написать этот раздел, но пока руки не дошли. Конечно же, можно собирать и без скриптов, и оффлайн.

В каталог, где находятся все локальные копии репозиториев Нusky, надо из huskybse/ скопировать huskymak.cfg для Линукса и huskymak.cfg.bsd для FreeBSD. Последний надо переименовать в huskymak.cfg. Туда же скопировать huskybse/Makefile. Запускать make/gmake надо будет в этом каталоге. Лучше всего эти действия выполнить с помощью wget и initbuild как это написано в huskybse/INSTALLru.asciidoc.

MAKE=make для Линукса и MAKE=gmake для FreeBSD. jobs - это количество логических процессоров, если на машине кроме сборки в данный момент ничего важного не делается. Иначе надо выбрать меньшее число. Но не меньше единицы. :-) Можно $jobs в командах, приведённых ниже, опустить. Тогда make/gmake будет выбирать сам, на сколько процессов можно распараллелить процесс сборки.

# Скачать обновления. Если репозиториев ещё нет, то склонировать все репозитории.
${MAKE} $jobs update

Это надо делать на машине с установленным git и с доступом в интернет. Всё остальное можно делать на машине без установленного git и без доступа в интернет.

# Сформировать файлы, показывающие, что от чего зависит в данном проекте
# и выполнить сборку
${MAKE} $jobs depend && ${MAKE} $jobs

Как установить собранные программы написано в в huskybse/INSTALL_ru.asciidoc. Возможно, я что-то забыл написать. Если что будет не так, пиши.

AS> При этом, init_build, в принципе, и при
AS> существующих исходниках (распакованных из архива) поправит вам конфиг
AS> для сборки,

init_ build надо запускать только один раз, для того, чтобы подготовить первоначальное скачивание исходников. И это написано в документации.

AS> * В случае FreeBSD 13 предлагаемый компилятор clang не сработает -
AS> сборка остановится на неисправимой ошибке в одном из файлов
AS> исходников. Решение: использовать gcc/g++ . Решение пришлось искать в
AS> портах более старой версии.

Решение неправильное. Надо привести кусок лога с ошибкой. Вообще-то я тестировал сборку во FreeBSD именно на 13.0, но это было какое-то время назад.

AS> * В общем мейкфайле сборки нет рецепта для hptutil. Или он больше не
AS> поддерживается? Отдельно собирать не пробовал.

Я не хотел включать hptutil, потому что когда-то тут были крики, что эта программа портит базы. Но, пожалуй, надо включить, чтобы получить подробное сообщение об ошибке. :)

Желаю успехов, Alex!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20181105

Alex Shuman написал(а) к Michael Dukelsky в Aug 22 02:10:49 по местному времени:


x) Sunday Jul 31, 2022, 20:21. Michael Dukelsky ── Alex Shuman.

AS>> Это всё про husky-all-1.9-source-20220708.zip

AS>> * Обе системы не любят CR/LF в .sh скриптах - было бы неплохо заменить
AS>> просто на LF уже в дистрибутиве.
MD> Разумеется, в репозитории на гитхабе никаких CR нет. Удали свою копию
MD> репозитория, содержащую CR, выполни команду

Да, вполне возможно, что это проблема того, кто создал и захатчил в файлэху husky-all-1.9-source-20220708.zip...

Я не пробовал получить именно с гитхаба, возможно, там всё ок.

AS>> * Нет скриптов для офлайн сборки - init_build и build.sh настойчиво
AS>> хотят гитхаб. В документации INSTALL единственной альтернативой
AS>> предлагается ручная сборка по "legacy makefiles" (но мне удалось
AS>> собрать и без них).
MD> Да, собирался написать этот раздел, но пока руки не дошли. Конечно же,
MD> можно собирать и без скриптов, и оффлайн.

MD> В каталог, где находятся все локальные копии репозиториев Нusky, надо из
MD> huskybse/ скопировать huskymak.cfg для Линукса и huskymak.cfg.bsd для
MD> FreeBSD. Последний надо переименовать в huskymak.cfg. Туда же скопировать
MD> huskybse/Makefile. Запускать make/gmake надо будет в этом каталоге. Лучше
MD> всего эти действия выполнить с помощью wget и init_build как это написано
MD> в huskybse/INSTALL_ru.asciidoc.

Да, я именно так и делал, но в случае ubuntu пришлось использовать init_build , который нашёл мне правильный huskymak.cfg . По ходу, проблема в том, что я использовал для ubuntu huskymak.cfg.debian в качестве основы, а в нём, почему-то, нет PROGRAMS= и в итоге получилось "нет целей для сборки".

build.sh же до этапа сборки мне довести не удалось. Возможно, его стоит поправить, добавив возможность пропустить обновление исходников, т.е. собирать из того, что уже есть в каталогах...

MD> ${MAKE} $jobs depend && ${MAKE} $jobs

А это был корень проблемы, я долго думал, почему "нет целей для сборки" sqpack и прочего, с указанием на какие-то несуществующие .d файлы, потом внимательно почитал build.sh...

MD> Как установить собранные программы написано в в
MD> huskybse/INSTALL_ru.asciidoc. Возможно, я что-то забыл написать. Если что
MD> будет не так, пиши.

да там просто make install и всё устанавливается, куда в конфиге и прописал...

AS>> При этом, init_build, в принципе, и при
AS>> существующих исходниках (распакованных из архива) поправит вам конфиг
AS>> для сборки,
MD> init_ build надо запускать только один раз, для того, чтобы подготовить
MD> первоначальное скачивание исходников. И это написано в документации.

А ещё он найдёт правильный huskymak.cfg.

AS>> * В случае FreeBSD 13 предлагаемый компилятор clang не сработает -
AS>> сборка остановится на неисправимой ошибке в одном из файлов
AS>> исходников. Решение: использовать gcc/g++ . Решение пришлось искать в
AS>> портах более старой версии.
MD> Решение неправильное. Надо привести кусок лога с ошибкой. Вообще-то я
MD> тестировал сборку во FreeBSD именно на 13.0, но это было какое-то время
MD> назад.

В порте, где так сделали, объяснили это несовместимостью определённой версии clang. Впрочем, я нашёл проблему. На той машине с FreeBSD остались инклюды от этого порта, вот он в итоге и ругался на

/usr/local/include/fidoconf/common.h:166:38: note: passing argument to parameter 'aka' here
НUSKYEXT char *aka2str(const hs_addr aka);
^
hpt/src/carbon.c:109:34: error: passing 'hsaddr ' (aka 'struct _netaddr ') to parameter of incompatible type 'hs_addr' (aka 'struct netaddr'); remove &
msg->netMail ? aka2str(&msg->destAddr) : "");
^~~~~~~~~~~~~~

...и прочее в том же духе. Пришлось почистить инклюды из /usr/local, сделать заново gmake depend и вот тогда собрался и с помощью clang.

В общем, логика поиска инклюдов сначала в системных путях, и только потом в локальных каталогах - то ещё извращение, зачем так делать...

А gcc, видимо, делает наоборот, т.е. более логичным путём, поэтому собиралось и так.

AS>> * В общем мейкфайле сборки нет рецепта для hptutil. Или он больше не
AS>> поддерживается? Отдельно собирать не пробовал.
MD> Я не хотел включать hptutil, потому что когда-то тут были крики, что эта
MD> программа портит базы. Но, пожалуй, надо включить, чтобы получить
MD> подробное сообщение об ошибке. :)

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

--- Neon BBS Line 2, 570-57-80, 20:30-06:30. [bbs.ncc.org.ua]

Michael Dukelsky написал(а) к Alex Shuman в Aug 22 10:01:40 по местному времени:

Привет, Alex!

01 Aug 22 02:10, Alex Shuman послал(а) письмо к Michael Dukelsky:

AS>>> Это всё про husky-all-1.9-source-20220708.zip

AS>>> * Обе системы не любят CR/LF в .sh скриптах - было бы неплохо
AS>>> заменить просто на LF уже в дистрибутиве.
MD>> Разумеется, в репозитории на гитхабе никаких CR нет. Удали свою
MD>> копию репозитория, содержащую CR, выполни команду
AS> Да, вполне возможно, что это проблема того, кто создал и захатчил в
AS> файлэху husky-all-1.9-source-20220708.zip...

Нет, это твоя проблема. Файл husky-all-1.9-source-20220708.zip создал Max Vasilyev, который занимается сборкой программ под Windows и OS/2. Соответственно, там все файлы содержат CR/LF. Зачем ты взял этот файл? Разве в инструкции было написано, что надо брать виндовые исходники из файлэхи? Нет, там было написано, что исходники надо брать с гитхаба. Ты с самого начала отошёл от инструкции и с этого начались твои многочисленные проблемы и мучения. Инструкции пишут для того, чтобы им следовать. Ты решил подойти к делу творчески. Ну и помучился слегка... :)

To Max Vasilyev: впиши в file_id.diz, что исходники предназначены для компиляции в Windows и поэтому содержат CR/LF в концах строк.

Желаю успехов, Alex!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20181105

Michael Dukelsky написал(а) к Alex Shuman в Aug 22 12:16:04 по местному времени:

Привет, Alex!

01 Aug 22 02:10, Alex Shuman послал(а) письмо к Michael Dukelsky:

AS> build.sh же до этапа сборки мне довести не удалось. Возможно, его
AS> стоит поправить, добавив возможность пропустить обновление исходников,
AS> т.е. собирать из того, что уже есть в каталогах...

Сделал.

Желаю успехов, Alex!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20181105

Alex Shuman написал(а) к Michael Dukelsky в Aug 22 13:53:17 по местному времени:


x) Tuesday Aug 02, 2022, 10:01. Michael Dukelsky ── Alex Shuman.

AS>>>> Это всё про husky-all-1.9-source-20220708.zip
AS>>>> * Обе системы не любят CR/LF в .sh скриптах - было бы неплохо
AS>>>> заменить просто на LF уже в дистрибутиве.
MD>>> Разумеется, в репозитории на гитхабе никаких CR нет. Удали свою
MD>>> копию репозитория, содержащую CR, выполни команду
AS>> Да, вполне возможно, что это проблема того, кто создал и захатчил в
AS>> файлэху husky-all-1.9-source-20220708.zip...
MD> Нет, это твоя проблема. Файл husky-all-1.9-source-20220708.zip создал Max
MD> Vasilyev, который занимается сборкой программ под Windows и OS/2.
MD> Соответственно, там все файлы содержат CR/LF. Зачем ты взял этот файл?
MD> Разве в инструкции было написано, что надо брать виндовые исходники из
MD> файлэхи? Нет, там было написано, что исходники надо брать с гитхаба.

Я просто решил пойти фидошным путём, файлэха-то под рукой была. И да, там не было написано, что это исходники исключительно для сборки под Windows и OS/2 :)

--- Neon BBS Line 2, 570-57-80, 20:30-06:30. [bbs.ncc.org.ua]

Max Vasilyev написал(а) к Michael Dukelsky в Aug 22 14:46:44 по местному времени:

Нello Michael!

02 Aug 22 10:01, you wrote to Alex Shuman:

MD> To Max Vasilyev: впиши в file_id.diz, что исходники предназначены для
MD> компиляции в Windows и поэтому содержат CR/LF в концах строк.
Исходники для Windows.
Миша, ты жжёшь!
Видимо текущая используемая версия git кривая, если переводы строк принудительно меняет - вот с этим разберусь.

WBR, Max.
--- скучаю по FleetStreet'у :-(((

Michael Dukelsky написал(а) к Max Vasilyev в Aug 22 12:38:26 по местному времени:

Привет, Max!

18 Aug 22 14:46, Max Vasilyev послал(а) письмо к Michael Dukelsky:

MD>> To Max Vasilyev: впиши в file_id.diz, что исходники предназначены
MD>> для компиляции в Windows и поэтому содержат CR/LF в концах строк.
MV> Исходники для Windows.
MV> Миша, ты жжёшь!
MV> Видимо текущая используемая версия git кривая, если переводы строк
MV> принудительно меняет - вот с этим разберусь.

Макс, ты жжёшь! В Windows стандартно git при выполнении fetch преобразует концы строк к виду, принятому в Windows, то есть к CR/LF. И это правильное поведение. Называть его кривым как-то странно.

Желаю успехов, Max!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20181105

Alex Shuman написал(а) к Michael Dukelsky в Aug 22 19:15:14 по местному времени:


x) Friday Aug 19, 2022, 12:38. Michael Dukelsky ── Max Vasilyev.

MD>>> To Max Vasilyev: впиши в file_id.diz, что исходники предназначены
MD>>> для компиляции в Windows и поэтому содержат CR/LF в концах строк.
MV>> Исходники для Windows.
MV>> Миша, ты жжёшь!
MV>> Видимо текущая используемая версия git кривая, если переводы строк
MV>> принудительно меняет - вот с этим разберусь.
MD> Макс, ты жжёшь! В Windows стандартно git при выполнении fetch преобразует
MD> концы строк к виду, принятому в Windows, то есть к CR/LF. И это правильное
MD> поведение. Называть его кривым как-то странно.

Это кривое поведение, костыль. Примерно, как фидошную букву автозаменять. Лучше бы отдавалось всё в одном, неизменном виде (т.е., как заливалось).

Может, платформенно-специфичные вещи типа sh скриптов там лучше хранить в бинарном виде тогда?

--- Neon BBS Line 2, 570-57-80, 20:30-06:30. [bbs.ncc.org.ua]

Alexey Vissarionov написал(а) к Alex Shuman в Aug 22 05:55:56 по местному времени:

Доброго времени суток, Alex!
19 Aug 2022 19:15:14, ты -> Michael Dukelsky:

MV>>> Видимо текущая используемая версия git кривая, если переводы строк
MV>>> принудительно меняет - вот с этим разберусь.
MD>> Макс, ты жжёшь! В Windows стандартно git при выполнении fetch
MD>> преобразует концы строк к виду, принятому в Windows, то есть к CR/LF.
MD>> И это правильное поведение. Называть его кривым как-то странно.
AS> Это кривое поведение, костыль. Примерно, как фидошную букву
AS> автозаменять. Лучше бы отдавалось всё в одном, неизменном виде
AS> (т.е., как заливалось).
AS> Может, платформенно-специфичные вещи типа sh скриптов там лучше
AS> хранить в бинарном виде тогда?

man git-config
/crlf


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Только дурак нуждается в порядке - гений господствует над хаосом
--- /bin/vi