Введение
Решая в целом тривиальные задачи, приходится сталкиваться с нетривиальными проблемами, и эта история, собственно, об этом.
В кои-то веки, решив написать код для себя любимого, проработал проект, установил окружение, прописал в проекте boost и пошёл писать модули.
Ничто не предвещало беды, но в процессе написания кода было обнаружено, что модуль, который запрашивал у интернета погоду, получал вместо описанного в API json'а следующее: "400 The plain HTTP request was sent to HTTPS port". Уж чем руководствовался разработчик сайта, не перенаправивший запрос без персональных данных, не знаю, но видимо хакеры хотят украсть сведения о погоде в деревне так сильно, что спать и есть не могут.
И тут я сделал манёвр, который стоил мне 50 лет. Точнее, пары бессонных ночей, так как работать тоже надо. Ничтоже сумнящийся, подключил boost::asio::ssl, написал тестовый код, который должен был проверить что теперь есть контакт, но тут моя бровь поднялась вверх в первый раз: проект перестал собираться, потому что в системе не было OpenSSL.
Совсем открытием это конечно не было. В рабочих проектах мы писали код с использованием этого чуда, но сборкой занимался сервак, так как за каждым чихом перекомпилировать и пересобрать кодовую базу на рабочих станциях никто не желал, а на сервере всё заботливо было установлено. Все это позволяло пользоваться хедерами и лениться в плане ручной компиляции... Штош, дома нет сисадмина Лёхи, пришлось решать проблему ручками.
Что вас ждёт
Поиски.
Установка неожиданных вещей.
Настройка зоопарка.
Планирование установки.
Компиляция (много компиляции).
Причёсывание установки.
Интеграция в проект.
Поиски
Описываю, чтобы не пришлось этим заниматься вам. При поиске обнаружите два стула. На одном - сайты, испещерённые рекламой конкурентов оранжевого ютуба и обещаниями того, что в бинарниках вирусов нет (в установщиках кнопка доната есть, а цифровых подписей, чтоб антивирь не ругался, нет). На другом - официальный репозиторий, размещённый на официальном сайте проекта, вызывающий вьетнамские флешбэки о красноглазой студенческой молодости, но внушающий какое-то доверие.
Я предлагаю тебе взять красную таблетку и пройти за мной в кроличью нору.
Найди удобное место, открой консоль, склонируй репозиторий и погнали.
Установка неожиданных вещей
Изучив крайне информативную инструкцию, вы с толкнётесь с парочкой мыслей:
в 2022 году кто-то использует perl в успешном и развивающемся до сих пор проекте;
для проекта написанного на языке Си необходим ассемблер, ибо без него собирается не так споро;
о makefile создатели знают, но вместо них сборкой занимается perl, и тестированием, может быть ещё тапки приносит но это не точно.
В этот момент я отошёл за кофе и, когда пришёл в себя эмоционально, вернулся к процессу. Довольно приличным для себя нашёл Strwberry Pearl, предлагаемый в инструкции, да и NASM упомянутый в инструкции установился легко.
Веселье ждало позже.
Настройка зоопарка
Установив программки я выяснил ряд подводных камней:
Система не видит NASM.
Система знает про пути perl'а но тот perl который пытается выполнить ваши скрипты - это не тот perl который вы установили.
У меня были эти проблемы, и если вам что есть по этому поводу сказать, то приглашаю в комментарии.
Нам нужно поправить заблуждения системы о системных переменных.
Первая беда будет ждать в path системы:
NASM в процессе установки не умеет прописывать себя в путях так что третья строка снизу была добавлена вручную;
Perl умеет себя прописывать в путях системы но по какой то причине полностью рабочий исполняемы файл perl'а валяется в пользовательских бинарниках у git'а и вызывается вперёд нужного;
многие скрипты, необходимые perl'у, имеют в своём же расположении тёзку с расширением .bat и не вызываются нормально.
Последнее решается размещением расширения .pl в переменной pathext и перемещением его перед расширением .bat.
Далее понадобится перезапустить ПК, так как до сих пор это единственный путь, который гарантирует что переменные системы обновились.
На этом можем проверить факт того, что наши штуки установлены и настроены.
К сожалению, такой же прикол с перлом не пройдёт, так как помним, что в гите живёт его злобный брат-близнец, и надо убедится, что запускается нужный.
Если результат дальнейших действий как на картинках выше - успех
По шагам:
Запускаем перл в консоли.
В диспетчере задач находим процесс перла и заказываем подсмотреть где он живёт (мне удобнее через вкладку "подробности").
Если открывается путь, куда мы устанавливали его - радуемся.
А теперь можно прийти к последнему шагу настройки странных вещей - дополнительные пакеты perl:
Text::Template необходим для того, чтобы компилятор справился со своей работой;
Test::More нужен для того, чтобы можно было проверить: проходят ли полученные бинарники тесты.
Не стоит обманываться сообщением о том, что модуль уже есть. Скорее всего, он будет скачиваться и устанавливаться.
Ставить ли модуль тестов, это, конечно, дело индивидуальное, но если тесты есть, то зачем ими пренебрегать?
Планирование установки
Этап не обязательный, но лучше о нём подумать сразу, а не когда будет каша на диске.
Так как мы думаем про серьёзный проект, то понадобятся варианты, как на статической, так и на динамической сборке. Варианты для отладки и для разных систем - всё это надо как то складывать.
Для других платформ, например ARM, нужно будет создать дополнительные каталоги и выполнить команды по аналогии.
Сам же каталог скорее временный, так как библиотеки удобнее хранить в одном месте, и лично в моём случае, openssl переедет поближе к boost и другим используемым библиотеками, но позже.
Компиляция (много компиляции)
Дальше пойдут инструкции по сборке под конкретные варианты компиляции. При необходимости вы можете пролистать до нужных вам.
x64 Release dll
Здесь и в дальнейшем буду пользоваться приложением терминала Microsoft, но все терминалы, которые нужны для компиляции, доступны из меню Пуск в разделе установленной Visual Studio.
Для начала нужно открыть Терминал разработчика для x64 платформы и перейти в каталог репозитория, скачанного в самом начале.
А теперь понадобится perl. С помощью него настроим переменные сборки и подставим подготовленные каталоги для складирования данных компилятором.
Не нужно забывать, что пути нужно подставлять свои, и будет счастье. На следующем шаге возможно познать дзен, так как компилироваться это будет достаточно долго.
После команды nmake пройдёт ориентировочно 40 минут компиляции. Между первым и вторым кадром прошло 35 минут.
Дальше запуск тестов.
Чудные 20-30 минут тестов стоит провести за чем-нибудь более приятным, чем рябь от консоли.
Теперь нужно решить проблему девственно чистых папок, заготовленных под готовые библиотеки и дать команду компилятору.
Ждать на этом процессе меньше, но это не финал мытарств со сборкой данной версии. Надо прибрать за собой.
Вот теперь мы как пионеры - поработали и прибрали за собой.
x64 Release lib
Для статической библиотеки, находясь в каталоге репозитория, ввести настройки конфигурации для новой сборки. Как и в прошлый раз пользуемся перлом.
Необходимо указать каталог выходных файлов и добавить в конце ключ no-shared, это позволит собрать библиотеку для статической линковки.
Дальше шаги повторяют сборку динамической версии.
После команды nmake чем-нибудь займите себя, так как время сборки кардинально меньшим не станет.
Хотя в этом случае звёзды благоволили и сборка прошла за 20 минут, но никто не отменял тесты.
Тесты пройдены, пора устанавливать.
Команда установки обзавелась дополнительным суффиксом и хоть сработает и без него, но полученный результат не сработает в проекте так как надо.
Можно по выполнении команды убедиться что всё переместилось в нужный нам каталог.
Прибираемся, так как нефиг захламляться, да и последующим сборкам мешать будет.
x64 Debug dll
Процесс в целом довольно длительный и требует терпения, так что в этот раз, весь набор команд, необходимых для работы с конкретным вариантом сборки, я отправил в один пайплайн, который получился довольно увесистым.
perl Configure VC-WIN64A --debug --prefix=E:\soft\libs\movebox\dll\x64\debug --openssldir=E:\soft\libs\movebox\SSL && nmake && nmake test && nmake install_sw && nmake clean
Всё что выше - одна строка, и одной строкой же отправляется в консоль разработчика. При этом обратите внимание, что появился ключ debug в первой команде, и мы поменяли выходной каталог для библиотеки. Ключ для статической библиотеки здесь убран.
Вообще пайплайны устроены так, что если указан && между командами, то программы по данным между собой не связаны, но следующие запускаются только если предыдущие выполнились без ошибок, что позволяет узнать когда процесс пошёл не туда. С учётом того, что почти все команды, объединенные в пайп, длительные, и ловить каждые пару минут, закончилось оно или нет бывает проблематично, то запустить и забыть на часик другой про окно - довольно удобно.
Что приятно, так это то, что последующие шаги мы так же упростим а текущая команда подготовила место для работы после себя.
x64 Debug lib
Надеюсь, к этому моменту вы прониклись ленивостью, так как четвёртая компиляция пройдёт в такой же ускоренной манере.
perl Configure VC-WIN64A --debug --prefix=E:\soft\libs\movebox\lib\x64\debug --openssldir=E:\soft\libs\movebox\SSL no-shared && nmake && nmake test && nmake install_sw && nmake clean
В командах поменялись пути и добавлен ключ статической библиотеки, остаётся ждать.
Теперь мы закончили с билдом x64 платформы полностью и можно переходить к x86.
X86 all in one
Всё что нужно проделать для x86 платформы объединим в один скрипт.
perl Configure VC-WIN32 --debug --prefix=E:\soft\libs\movebox\lib\x86\debug --openssldir=E:\soft\libs\movebox\SSL no-shared && nmake && nmake test && nmake install_sw && nmake clean && perl Configure VC-WIN32 --prefix=E:\soft\libs\movebox\lib\x86\release --openssldir=E:\soft\libs\movebox\SSL no-shared && nmake && nmake test && nmake install_sw && nmake clean && perl Configure VC-WIN32 --debug --prefix=E:\soft\libs\movebox\dll\x86\debug --openssldir=E:\soft\libs\movebox\SSL && nmake && nmake test && nmake install_sw && nmake clean && perl Configure VC-WIN32 --prefix=E:\soft\libs\movebox\dll\x86\release --openssldir=E:\soft\libs\movebox\SSL && nmake && nmake test && nmake install_sw && nmake clean
Мешанина выше - это однострочный скрипт, который сделает всю необходимую работу по компиляции к размещению готового варианта библиотек. Но убедитесь, что запускаете вы его из под нужной консоли разработчика и в директории репозитория open ssl
И только после того, как убедитесь, что все условия соблюдены, запускаете нашу лошадку вывозить компиляцию.
Tips: Для большинства проектов достаточно собрать пару debug-release для конкретно вашей платформы и только в одном формате dll или lib.
Теперь пустых директорий в заготовленной папке у нас нет. Можно приступить к следующему шагу.
Причёсывание установки
После полностью прошедшего процесса установки и компиляции стоит почистить временные файлы
Папка ssl более не понадобится. Следующим шагом следует переместить библиотеку на постоянное место жительства. В случае с текущим компом, подобные библиотеки находятся в стандартном каталоге visual studio
Ну и библиотеки будут жить в папке libs
Переносим из временной папки библиотеки в заботливо созданную под это дело папку с названием библиотеки и версии. Так же переименуем папки с версиями для статической и динамической линковки - будет труднее запутаться так как lib и dll файлы будут фигурировать довольно часто, независимо от версии.
Интеграция в проект
Как видим, факт наших мучений с компиляцией не сильно впечатлил VIsual Studio, и нужно показать расположения вожделенных документов.
Так как в одном проекте нельзя одновременно подключать и статическую и динамическую версии одной и той же библиотеки, продемонстрирую пример подключения динамической версии, так как для отладки это может быть удобнее.
Нужно залезть в свойства проекта и перейти в настройки с/с++ и изменить настройки дополнительных включаемых каталогов.
В окне изменения с помощью магии макросов Visual Studio создадим универсальный путь включения.
Макросы помогут не один раз. Самое время проверить что теперь думает Visual Studio.
Ругаться стали по-другому. Теперь ошибки возникают не на уровне компиляции, а при линковке. Приблизились нас на шаг к победе.
Теперь нужно научит проект видеть исполняемые файлы dll и подключать в наш исполняемый файл вызовы нужной библиотеки.
Перво-наперво поясним компоновщику где лежат файлы вызовов функций. Добавим запись в дополнительные каталоги библиотек. Затем перейдя из вкладки общее в ввод дополним дополнительные зависимости.
libcrypto.lib;libssl.lib; - разделены ; которые нельзя забывать так что лучше через меню изменения
Теперь решение собирается и мы можем проверить что работает.
Отладка или релиз - не важно программа выдаёт:
Так как не научили проект знать о местоположении исполняемых файлов. Надо открыть свойства проекта и перейти в каталоги vс++
Нужный раздел - каталоги исполняемых файлов. Именно туда вписывают пути до библиотек dll.
![C:\Users\Varkmort-mainPC\source\libs\OpenSSL-master10.07.22\dynamic\$(PlatformTarget)\$(Configuration)\bin\](https://habrastorage.org/getpro/habr/upload_files/130/3be/31e/1303be31e2b6b6c27dcc4539c894d5af.png "C:\Users\Varkmort-mainPC\source\libs\OpenSSL-master10.07.22\dynamic\$(PlatformTarget)\$(Configuration)\bin\")
И вуаля - работает.
Теперь можно успокоится и со спокойным разумом продолжить работу над проектом, а не над войной со строптивой библиотекой.
Заключение
В процессе работы несколько раз были очень подлые моменты, например, что брандмауэр системы, на пару с антивирусом, просыпались из отключки и ломали компиляцию. x86 до рабочего состояния вовсе собралась раза с 4, и в конечном счёте была доустановлена только ради гайда. В данной статье постарался осветить возможные проблемы при работе и проведении процесса. Сколько я не искал на просторах рунета нормальных инструкций по развёртыванию open ssl, не нашёл таковых, и надеюсь на отклик со стороны читателей, а также на то, что статья будет полезна хотя бы ещё паре человек на этой планете. Успехов.
