LINUX.ORG.RU

Портабилизация приложения при сборке из исходников

 , , ,


0

1

Наверное сразу выделю основной вопрос - как заставить тот же ./configure принимать относительные пути (например -–prefix=./testbuild) вместо абсолютных. Ниже более подробные страдания

На текущий момент экспериментирую с различными костыльно-велосипедными применениями linux софта и возникла идея собрать «портативную» сборку lighttpd и php (собственно запустить и пощупать kodexplorer и его аналоги). Не хочу привязываться к пакетам из репозиториев и постоянно их настраивать т.к сейчас делаю это на десктопе, впоследствии если понравится, то перенесу на отдельный неттоп то ли с опенврт, то ли с дебианом, то ли еще с чем. В прошлый раз поднимал некстклауд на опенврт и забодался ставить и настраивать все, поэтому решил из исходников собирать все в отдельную папку и потом ее целиком переносить на разные системы. Вопрос дурости этой затеи понимаю, но тут просто интересно - как заставить тот же ./configure принимать относительные пути (например –prefix=./testbuild) вместо абсолютных. Ночью пытался собирать и получил

configure: error: expected an absolute directory name for –exec_prefix

в итоге временно собрал c префиксами /tmp/lighttpdsrv, соответственно бинарник в подпапке sbin, либы в подпапке lib и либы эти он по дефолту ищет как раз таки в

-m module directory (default: /tmp/lighhtpdsrv/lib)

что мне не нужно. Хочу по итогу получить папку, в которой будет lighttpd бинарник, рядом папка с либами и чтобы он искал ее по относительному пути, т.е запускать бинарник через ./testbuild/lighttpd, конфиг тоже рядом с бинарником, либы свои искал по пути ./testbuild/lib (естественно testbuild это название для примера). Понимаю и вижу, что все это через ./configure кастомизируется, но он требует только абсолютный путь - что я делаю не так, кроме самой идеи конечно же. Потом таким же образом еще думаю пхп как минимум добавлять, а там может и lua с мариадб например, дабы один раз все настроить и получить переносной вебсервер.



Последнее исправление: Dark_Snow (всего исправлений: 3)

поэтому решил из исходников собирать все в отдельную папку и потом ее целиком переносить на разные системы.

Тут такое дело, в большинстве случае программы собираются с динамической линковкой библиотек зависимостей. И просто перенести при динамической сборке может не получиться.

Тебе придётся и все зависимости тоже собирать и помещать в эту директорию, но glibc перенести не получится.

Программу с другой версией glibc, отличной от системной в большую сторону получится разве что в chroot или контейнере.

В случае chroot тебе придётся переносить всю систему.

Зачем?

В особенности может ещё не получиться, если ты собираешь программу на системе с очень новой версией glibc, а потом перенести хочешь на систему со старой, обратная совместимость есть, а вот вперёд не получится.

Не каждая программа предусматривая статическую линковку.

Не понятно зачем ты это делаешь. Бинарные дистрибутивы на то и придуманы, чтобы ты ставил пакет и ставились все его зависимости и пакет был собран правильно под окружение (систему) и далее нужно было только настроить его конфиги.

Идея муть какая-то.

Собирай тогда докер контейнеры.

anonymous
()
Ответ на: комментарий от anonymous

Вот докеры-шмокеры и прочую муть однозначно не хочу. Я готов и статически слинковать, не проблема - я уже с этим знаком ибо в андроид энтварь ставил и там всячески извращался. Зачем это надо, муть и прочее - я знаю что идея дурость, делаю just4fun. Образно говоря, пытаюсь повторить denwer, только для линукса. Вот за глибц напоминание спасибо - надо в чрут на сборочной системе ткнуть что-то постарее и в нем собирать, да

Dark_Snow
() автор топика

В теории ты мог бы собрать что-то статическое, в связке с каким-нибудь musl, так как glibc даже при статической линковке будет подгружать NSS плагины.

Но вообще ты какой-то фигнёй маешься. Постоянно что-то перенастраивать не нужно, я бы лучше копнул в тему почему тебе приходится каждый раз заниматься настройкой.

На крайняк, как сказал анон, докер как раз для таких вещей и существует.

a1ba
()

В chroot всё держи. Его и таскай. В нём всё и разворачивай. Это дабы обойти необходимость явно собирать все зависимости. Минимальный дистрибутив через debootstrap или аналог разворачиваешь, внутри что надо ставишь или компиляешь.

PREFIX всегда должен быть абсолютным, а вот DESTDIR может быть чем угодно, он подменяет корень. Ты можешь собрать например так --prefix=/usr/local, а DESTDIR для установки задать как ./myexperimentdir и получишь такое ./myexperimentdir/usr/local если ты сделаешь chroot ./myexperimentdir (где должна быть оболочка ещё быть в ./myexperiment/bin/sh) ты с делашь так что для программ будет видно просто /usr/local/чётотам.

Но это лишь один из путей, либо симулируешь корень системы, чрут,докер,фигокер. Либо собираешь вообще все завимсимости, укладываешь их как тебе угодно и через LD_PRELOAD LD_LIBRARY_PATH задаёшь откуда всё будет браться из выдуманной тобой структуры каталогов, может ещё придётся расковырять ПО которое не подразумевает что будет запускаться из произвольного места с произвольным расположением ресурсов.

Для некоторого ПО твоё желание реализуется очень просто и без костылей, а с некоторым придётся плясать если хочешь прям всё сам, просто оно предполагает некие договорённости о том что и где лежит, а ты хочешь свои. Либо дай этому ПО эти договорённости развернув всё в чруте или его аналоге, либо придётся (и в этом нет ничего такого просто сложнее) делай специализированную сборку.

Если с одной двумя программами как бы ладно, а вот с комплексом программ которые друг с дружкой взаимодействовать будут уже сложнее, надо понимать как и через что они взаимодействуют.

Конпиляй в чруте короче =) Чрут просто каталог с файлами получится,со всеми программами, библиотеками и настройками.

Про appimage сказали ещё. Но там тоже курить надо. Хотя можно чрут в appimage целиком запихать и получить 1 файлик для запуска вообще всего.

А можно просто ход конём, скрипт который тебе на другой машине всё установит, запишет конфигурацию в конфиги, что надо запустит и всё.

Путей много, у тебя проблемы с тем что есть предопределённые вещи которые ты хочешь сделать по своему, опять де ничего такого, но только надо будет раз уже делать то прям делать всё по своему.

Ну и от ПО зависит, собрать луа и таскать бинарник с собой куда угодно это одно, а собрать мариадб и её таскать это другое :) Я второе не пробовал, но кажется не всё пойдёт гладко если делать влоб

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)
Ответ на: комментарий от Dark_Snow

Образно говоря, пытаюсь повторить denwer, только для линукса.

Набор скриптов, которые в зависимости от дистрибутива rpm-based / deb-based и его версии ставят из штатного репозитория:

  • apache2 / nginx
  • php, php-fpm, модули
  • mysql / postgresql
  • perl, python
  • что-то ещё
  • добавляют твои самописные скрипты перечитывания конфигов и перезапуска сервисов
  • добавляют в sudo вызов скриптов
  • добавляют в /etc/nginx, /etc/apache2 подключение директорий с конфигами пользователя или в скриптах запуска указать, что директорию с конфигом бери не из /etc/, а из вот такого-то места.

В Linux от обычного пользователя сервис не может слушать 80 и 443 порты, поэтому всё равно нужен будет sudo или запуск apache2 / nginx / lighttpd на нештатных портах.

В общем, я вижу то, что ты хочешь в другой реализации.

Накидал тебе как идею подумать.

Как ты будешь делать - дело твоё.

Denver - это в первую очередь набор скриптов для удобства пользователя, ставящих нужный софт и позволяющий его перезапускать.

Софт уже есть в репозиториях.

Не всё продумал, но в общей канве примерно так.

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

В целом поддерживаю. Но автору, видимо, не хватает опыта, поэтому и выдумывает всё это.

Я бы ещё добавил - переносить всё это в squashfs образе, а для записи использовать каскадную ФС, overlayfs или aufs или другую.

Ну и немного скриптов для автоматизации запуска.

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

Конпиляй в чруте короче =) Чрут просто каталог с файлами получится,со всеми программами, библиотеками и настройками.

Если он будет в chroot и конпелять, то в chroot будут установлены сборочные зависимости, тот же компилятор хотя бы, заголовочные файлы библиотек и их исходники, т.е. всё то, то для запуска разрабатываемого решения не нужно.

По хорошему нужно собирать в одной системе, а ставить в другую. Чтобы chroot для переноса получился небольшого размера.

Иначе вообще теряется смысл.

Но выглядит всё как велосипед с пятью колёсами.

Уже давно существую докер контейнеры или есть готовые пакеты в дистрибутивах.

ТС, конечно будет делать так, как решит, только сложно будет ему одному всё сделать, лучше использовать уже существующие варианты.

anonymous
()
Ответ на: комментарий от rtxtxtrx

На счёт того, что в представленной по ссылке диаграмме caddy показан на большем проценте сайтов, по сравнение с lighttpd не говорит о том, что он модный.

Даже там:

  • caddy - 0.2%
  • lighttpd - 0.1%
  • nginx - 34.2%

Ну такой себе модный, меньше 1%, при том, если даже вместе с lighttpd сложить, согласно диаграмме, тоже меньше 1% )))

Остальное, видимо - apache2 IIS, tomcat, всякие java, python, nodejs в dev режиме.

Интересное у тебя определение слова модный.

anonymous
()
Ответ на: комментарий от anonymous

Говорит. Вся эта маргинальщина (в тч Traefik) по отдельности даже 0.2% перешагнуть не может и мало где используется. Модный в кавычки заверни. Я не обязан везде иронию как-то выделять

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)

Не имел дела с lighttpd, но есть три соображения:

1) Тебе точно нужна динамическая сборка с отдельными so? Может быть там есть статическая в один бинарник, и ни с какими путями к модулям не придётся возиться.

2) Возможно, путь можно переопределить где-то в конфиге уже после компиляции.

3) Найди в исходнике где это всё реализовано и поправь, скорее всего там всё просто.

firkax ★★★★★
()
Ответ на: комментарий от a1ba

через scons собрал fullstatic, он даже префикс ./srv принял - надо тесты гонять. ну и собирать в чруте со старыми масл и\или глибц - при сборке оно прямо предупреждает о проблемах при несовпадении версий

Dark_Snow
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Я чрут на дроиде в энтвари юзаю, да. Причем даже иксы запускаю. Мне чисто из сорцев статически собрать веб сарвар, пыху, монгу, ну и что там еще вероятно, мне не собирать целую ось)

Dark_Snow
() автор топика
Ответ на: комментарий от anonymous

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

Dark_Snow
() автор топика
Ответ на: комментарий от anonymous

ТС пока осваивает статическую линковку на лайте, потом если идея взлетит, то пойдет пыху трогать. Если чрут делать, то зачем в нем собирать что-то, вместо апт-гет инсталл? Я могу в чруте, да, просто это просто и скучно, интереснее норко-манить. Да и плясать между несколькими чрутами если вдруг, вот не хочется

Dark_Snow
() автор топика
Ответ на: комментарий от firkax

Мне фиолетово, динамик или статик. «Переопределить» только через -м и папка с модулями - не хочу лишнего, хочу сразу по дефолту ./lib Вопрос не к сорцам, вопрос к ./configure, который требует абсолютный путь префиксов.

Пока что собрал статик через scons, буду проверять работоспособность.

Dark_Snow
() автор топика
Ответ на: комментарий от Dark_Snow

Учти что «относительный путь» и «путь относительно расположения бинарника» это разные вещи. Текущая директория при запуске демонов традиционно не пойми какая, и опираться на неё не принято. Если ты будешь запускать его всегда вручную и удостоверившись что перед этим сделано правильное cd - то норм, но cd само по себе лишнее действие, не вижу особой разницы с указанием -m.

firkax ★★★★★
()
Ответ на: комментарий от Dark_Snow

Образно говоря, пытаюсь повторить denwer, только для линукса.

denwer под виндой нужен из-за того, что там нет штатных apache/nginx/mysql/php, либо самому всё ставить и сопрягать, либо denwer. Под линуксом же всё в штатных репах есть, совершенно непонятен смысл заменителя denwer под линуксом.

Dimez ★★★★★
()
Ответ на: комментарий от firkax

Не, естественно запускать буду из папки, ну или с указанием полного пути до бинарника. А ежели по запаре забуду указать через -м? Всякое бывает, да и кмк, лучше уж «по-человечески» делать сразу…

Dark_Snow
() автор топика
Ответ на: комментарий от anonymous

Наконец-то работа чуть отпустила и смог проверить - таки такой вариант оно проглотило, но! Оно установило путь либ путем к каталогу сборочному, не на относительный… Но буду пробовать дальше в свободное время - все же интересно победить)

Dark_Snow
() автор топика
Ответ на: комментарий от Dark_Snow

ну или с указанием полного пути до бинарника

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Такс, подожди… Ты если можешь, то объясни пожалуйста про пути подробнее, либо ткни неразумного, где почитать - я понимаю, что в чем-то не прав, но не пойму в чем. Основная идея - чтобы программа искала либы не по пути от / , а по пути от своего места запуска, т.е от ./ - но ты пишешь интересные вещи, о которых я в принципе не знал.

Dark_Snow
() автор топика
Ответ на: комментарий от Dark_Snow

Суть в том, что ./ - это то, куда был сделан cd перед этим. Сделан вручную. Просто запуск проги /d1/d2/bin не делает cd /d1/d2 сам по себе (иначе бы после запуска например баша у тебя текущая директория всегда становилась /bin т.к. он в ней лежит). А ещё - прога в ходе своей работы может сама сделать cd куда-то там (хотя вроде бы так редко делают) - и опять все относительные пути станут указывать не туда.

Я, признаюсь, код nginx и код php на этот счёт не смотрел, может быть там что-то предусмотрено на ту тему. Но это должно быть именно специально предусмотрено, вот просто само по себе оно работать не будет.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 4)
Ответ на: комментарий от firkax

Кратко говоря, если получать то что я хочу, то мне поможет только полностью статичная линковка в один бинарник? Либо sfx архив, с распаковкой в тот же /tmp к примеру и запуском оттуда (естественно все это сконфигурировано на соответствующие пути перед сборкой).

Dark_Snow
() автор топика
Последнее исправление: Dark_Snow (всего исправлений: 1)
Ответ на: комментарий от Dark_Snow

Нет, тебе ещё путь к конфигам надо фиксить будет. Варианта три:

1) делать вручную нужное cd перед запуском демона

2) указывать пути в аргументах запуска демона

3) исправить исходник чтобы относительные путь он считал относительно своего бинарника а не относительно ./

Распаковка в tmp это какая-то чушь.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Есть классическое решение через враппер на sh.

Допустим, у нас есть прога proga. Переименовываем proga в proga.bin. Создаём файл proga, куда пишем sh-скрипт. Этот скрипт при запуске детектирует путь, из которого запущен. Затем с учётом этого пути выставляет все нужные переменные окружения так, чтобы программа работала корректно, и вызывает proga.bin. При необходимости можно делать cd в нужный каталог и вообще что угодно, благо у нас в распоряжении полноценный скриптовый язык.

Другой путь – это сразу писать программу так, чтобы она понимала относительные пути. Хороший пример ­— это gcc, в нём же можно посмотреть, как это реализовано: Прибитые к ./configure --prefix=/usr программы...

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Я думал и за враппер и прочее, НО! - при сборке, в бинарник записывается дефолтный путь по которому он свои библиотеки ищет, вот по сути я хочу заставить его в себе путь иметь относительно бинарника, чтобы не морочиться (что само по себе не трудно, но некрасиво) и в самом хелпе бинарника красиво было

Dark_Snow
() автор топика
Ответ на: комментарий от firkax

У меня вопрос изначально не про запуск бинарника, а про его сборку - почему ./configure требует полный путь и почему он заколачивается гвоздями. Вот щитдовс терпеть не могу (начиная с 8 и выше), но блин, у них софт без врапперов либы сначала из своего каталога подхватывает и много чего еще полезного….

Dark_Snow
() автор топика
Ответ на: комментарий от Dark_Snow

Потому что в винде традиционно каждая прога записывается абы куда и возможно в разные места, и они к этому приспособились. В линуксе принято иметь стандартное расположение всего софта, поэтому обычно софт не утруждает себя вычислениями относительных путей.

firkax ★★★★★
()
Ответ на: комментарий от Dark_Snow

Ты сам выше писал что хочешь просто запускать и не хочешь никакие аргументы бинарнику передавать. Если б ты допускал скрипт-обёртку то засунуть эти аргументы в него вроде очевидное решение, я его даже упоминать не стал.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Это в идеале - все равно будет скрипт запуска веб сервера, пхп и прочего, однако хотелось бы не использовать ключ -м в lighttpd и в хэлпе его видеть левый путь

Dark_Snow
() автор топика