Здравствуйте, Sheridan, Вы писали:

V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта
S>В /usr/bin ??? Ничего не попутали?!

В GNU/Linux часто используют вторичную иерархию /usr/* и третичную /usr/local/*, но речь не о них. Как крайний случай того о чём говорю это:

Переносимое приложение (также портативное, автономное, и — неточно, в качестве кальки — портированное; англ. portable application, portable app) — программное обеспечение, которое для своего запуска не требует процедуры установки и может полностью храниться на съёмных носителях информации, что позволяет использовать данное ПО на многих компьютерах.

То есть в общем случае приложение отправится в /opt/*, но по сути может быть где угодно, например, в /home/*, /media/*, /mnt/*.

Чисто для примера, берём исполняемый файл скомпилированной мною программы memories-console и запускаем просмотр зависимостей.

ldd /mnt/data_00/archive/files/work/memories-console

Результат.

linux-vdso.so.1 (0x00007ffe28fc4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f26dab1b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f26da799000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f26da495000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f26da27e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f26d9edf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26daf3f000)

Аналогично можно сделать для Windows, именно о таком копировании и говорилось в предыдущем комментарии. Дело в том, что лично я использую Windows и GNU/Linux в мультизагрузке. Я и там и там проводил опыты по статической линковке, по динамической с переносом динамических библиотек в одну папку или настройку окружения и так далее. У меня нет предубеждений, что подходы Windows работают только в Windows, а подходы GNU/Linux только в GNU/Linux. Если в Windows существует возможность засрать системный реестр, то это не значит, что надо делать именно так. Если в каком-то дистрибутиве GNU/Linux есть порядок установки приложений из репозитория, то это не значит, что обязательно нужно к этому привязываться. С одной стороны вроде бы удобно, а с другой Ubuntu насколько помню обновляется раз в пол года, Debian раз в 2 года и так далее.

Меры против DLL hell

Здравствуйте, Sheridan, Вы писали:

V>>В GNU/Linux могу предложить очень тупой, но рабочий способ — просто запихивать сторонние динамические библиотеки алгоритмов в папку с исполняемым файлом проекта
S>В /usr/bin ??? Ничего не попутали?!

В GNU/Linux часто используют вторичную иерархию /usr/* и третичную /usr/local/*, но речь не о них. Как крайний случай того о чём говорю это:

Переносимое приложение (также портативное, автономное, и — неточно, в качестве кальки — портированное; англ. portable application, portable app) — программное обеспечение, которое для своего запуска не требует процедуры установки и может полностью храниться на съёмных носителях информации, что позволяет использовать данное ПО на многих компьютерах.

То есть в общем случае приложение отправится в /opt/*, но по сути может быть где угодно, например, в /home/*, /media/*, /mnt/*.

Чисто для примера, берём исполняемый файл скомпилированной мною программы memories-console и запускаем просмотр зависимостей.

ldd /mnt/data_00/archive/files/work/memories-console

Результат.

linux-vdso.so.1 (0x00007ffe28fc4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f26dab1b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f26da799000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f26da495000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f26da27e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f26d9edf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26daf3f000)

Аналогично можно сделать для Windows, именно о таком копировании и говорилось в предыдущем комментарии. Дело в том, что лично я использую Windows и GNU/Linux в мультизагрузке. Я и там и там проводил опыты по статической линковке, по динамической с переносом динамических библиотек в одну папку или настройку окружения и так далее. У меня нет предубеждений, что подходы Windows работают только в Windows, а подходы GNU/Linux только в GNU/Linux. Если в Windows существует возможность засрать системный реестр, то это не значит, что надо делать именно так. Если в каком-то дистрибутиве GNU/Linux есть порядок установки приложений из репозитория, то это не значит, что обязательно нужно к этому привязываться. С одной стороны вроде бы удобно, а с другой Ubuntu насколько помню обновляется раз в пол года, Debian раз в 2 года и так далее.
Меры против DLL hell

1. подсчитать контрольную сумму кода функции, вызываемой из DLL — сравнить с контрольной суммой функции, используемой при написании программы.
2. Операционная система должна поставляться совместно с менеджером пакетов, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование менеджера пакетов должно поощряться, а индивидуальная инсталляция DLL — по возможности отвергаться.
3. Централизованное распространение библиотек.
4. Допустить возможность параллельного использования нескольких версий одной и той же DLL.
5. При модификации программного обеспечения для частного использования поставлять также модифицированные версии DLL.
6. Во время проектирования DLL должна тщательно продумываться концепция функций и версий.
7. DLL не должны использоваться без необходимости, а библиотеки, связанные только с одним приложением, должны подключаться статически (в EXE-файл).

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