SU.C_CPP----------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 23 из 100
 От   : Valentin Nechayev                   2:463/68.300      07 май 23 09:14:44
 К    : Eugene Muzychenko                                     07 май 23 10:09:28
 Тема : Развитие языка
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:463/68.300 6457460c
@REPLY: 2:5000/14 642302d5
@CHRS: CP1125 2
@TZUTC: 0300
@TID: hpt 1.2.4-release/bsd 30-05-03
 Hi,

 >>>> Eugene Muzychenko wrote:

 EM> Так проблем ж не в сборке под "родной" дистрибутив, под которым
 EM> работает сама система сборки, а под какой-то другой. И с этим, по
 EM> словам линуксоидов, такая жопа, что им проще всегда собирать под
 EM> целевой системой,

При различии вида RH vs. Debian - да.

 EM>  притащив туда все нужные заголовки/библиотеки, даже
 EM> если они там больше никогда не понадобятся.

Hет.
 Делаешь базовый сборочный образ на docker (podman, etc. - кому что
актуальнее сейчас).
Через apt-get install // dnf install // etc. подключаешь к нему нужные
 библиотеки, и вот тут можешь это сделать один раз на проект (хотя
лучше два - перед релизом обновить базу и проверить работу), можешь один
раз в неделю или месяц, можешь перед каждой сборкой. Ап ту ю.
И в этом контейнере уже собирать.

 Последние лет 5 почти однозначно, 10 - вероятно, это лучший вариант
по соотношению результата к затратам.

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

 (Кстати, докер на Windows тоже неплохо работает. Hо уже с полной
эмуляцией, естественно, уровня где-то Hyper-V или WSL.
И про WSL не забывать, если дистрибутив поддерживается в ней.)

 Впрочем, на одной из работ, с которой я не теряю связи, вместо
этого образы под VirtualBox с установкой через vagrant. Чем-то даже
удобнее.

 Во всех этих вариантах можно также наладить среду типа CLion ходить
в них для отладочных запусков, он умеет и ssh, и docker exec.

 EM>>> попадает что-то левое, но подавляющее большинство там родного, в
 EM>>> виде hard links в WinSxS. :)

 VA>> И вот это как раз очень хреново. Ведь почти каждая программа
 VA>> тянет с собой ВСЕ свои зависимости.

 EM> Зависимостей у программы (ее исполняемого файла) бывает две: "сугубо
 EM> личные", когда часть кода/данных выделена в DLL чисто для удобства, и
 EM> общие, когда ими пользуются разные программы. В первом случае ничего
 EM> лучшего, как положить DLL в один каталог с исполняемым файлом (или в
 EM> его подкаталоги, если так удобнее), придумать нельзя. Во втором общие
 EM> ресурсы оформляются в assembly, которая устанавливается в WinSxS, а в
 EM> программе указывается, что она зависит от определенных assemblies. Все
 EM> ссылки идут по уникальным именам, формируемых из базовых имен, версий
 EM> и контрольных сумм, так что вероятность коллизии практически нулевая.

 Вот вариант с контрольной суммой сборки мне нравится. Реально красиво
и эффективно.

В Unix на системном уровне не принято, но, например, Rust использует его вовсю.

 VA>> Это не ограничение, а очень разумный дизайн. Просто людям,
 VA>> которые пришли из мира Windows он непривычен.

 EM> В каких мирах, кроме линуксового, принято класть в общесистемные
 EM> каталоги "личные" библиотеки приложения, которые гарантированно не
 EM> потребуются никому другому?

 В Linux такое не принято, это тебя обманули (или ты сам). Hу
кроме, может быть, чисто хакерских дистрибутивов типа Slackware.

 В общесистемные каталоги ставится только через пакетный менеджер
дистрибутива, а сборка дистрибутива отслеживает конфликты и там не может быть
дублей.
 Более того, это "=>" только в одну сторону, и все, кто может и
хоть как-то подумал (или его запинали), делает свои подкаталоги в
каком-нибудь /usr/lib и подключает их системными средствами.

Вот я быстренько пробежался по ближайшей CentOS машинке и узрел:

$ ldd `which dovecot`
        linux-vdso.so.1 (0x00007ffeb6335000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f96a31cb000)
  libdovecot.so.0 => /usr/lib64/dovecot/libdovecot.so.0
(0x00007f96a2dfa000)
...

А вот за счёт чего это возможно:

 objdump -x `which dovecot` | grep RPATH
  RPATH                /usr/lib64/dovecot

Там динамически ещё десяток библиотек цепляется, но это уже явным dlopen().


-netch-

... Встрял перст в ноздрь...

---
 * Origin: Dark side of coredump (2:463/68.300)
SEEN-BY: 50/109 250/25 301/1 341/66 450/1024 451/31
452/28 166 455/19 460/58
SEEN-BY: 463/68 877 1331 467/4 888 4500/1 5000/111
5001/100 5005/49 5010/352
SEEN-BY: 5015/42 46 5020/113 545 620 715 830 846
848 1042 4441 12000 5022/128
SEEN-BY: 5030/49 115 1081 5036/26 5049/1 5053/51
5054/89 5058/104 5059/37
SEEN-BY: 5064/56 5083/1 6090/1
@PATH: 463/68 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх