Как создать проект и закрыть код при последующей установке. Что бы кроме деассемблера не прочесть.

Все такие ярые защитники опенсорса, а на работе (кто программер) сами пишите проприетарщину и не гундите, ибо бабло. И конечно у всех на компе только опенсорс :). Это ханжество, господа.

мои клиенты могут читать сорцы покупаемого софта. платят-то они за деливери и саппорт. у вас не так? значит у вас плохие клиенты или сам софт :)

С rpath проблема высосана из пальца. Оно позволяет указывать относительные пути, так что все пучком встанет как в хомяк, так и в опт.

Я стартовые скрипты наоборот не люблю, попахивает костылями.

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

Устанавливай недолинкованные бинарники, как это Oracle делает. Линкуй при установке. Или линкуй бинарник статически.

Читал статьи, в которых написано, что под разные версии Linux придётся перекомпилировать код.

под разные версии Windows, кстати, код тоже надо перекомпилировать. Просто в силу объективных причин там разных версий меньше. Чтобы минимизировать усилия ориентируйтесь на стандарты (LSB,POSIX и иже с ними), а не на конкретный/любимый диструбутив. Не увлекайтесь нестандартными,неустоявшимися (пусть даже мега-удобными) библиотеками.

Но я не хочу оставлять свой код открытым.

Код полностью Ваш ? Написан не на заказ, не на наёмной работе ? Будем считать, что Вы - правообладатель. Как правообладатель Вы должны понимать, что «спасение утопающих - дело рук самих утопающих», то есть на защиту своих прав, Вы должны тратить свои ресурсы (время/деньги). И чем более жесткие требования Вы наложите на лицензии, тем больше ресурсов потратите. Закрытие кода - достаточно жёсткое требование и требует как минимум организацию хорошей тех.поддержки.

Делегируя часть своих прав конечному пользователю (право ознакомиться с исходником или даже модифицировать код для своих нужд/своего дистрибутива) вы сокращаете собственные издержки. То есть чем больше кода открыто, тем Вам дешевле и проще поддерживать продукт.

Теперь самый главный момент - какова цель закрытия кода? Вариантов не так много :

1) Код содержит коммерчески значимые компоненты (библиотеки, удачные решения каких-то проблем, хитрые алгоритмы)

2) Нестандартный, но чрезвучайно удобный в предметной области интерфейс пользователя

3) Ваша система работает с конфиденциальными или критическими данными и Вы хотите гарантировать пользователю, что в полученном им продукте нет не-ваших добавлений.

4) вы боитесь, что некто, лёгким движением руки, поменяв пару-тройку десятков строк в исходнике выпустит то-же, но под другим лейблом.

5) в коде есть пи@$%женные части и вы это скрываете

6) присутствуют недекларированные возможности

7) код, как и программа - полная лажа и показывать это по крайней мере стыдно

8) вы богатый жлоб :)

соответсвенно делается и закрытие:

для п1,2 та часть которая важна реализуется с минимальными зависимости от сторонних библиотек, документируется API, собирается и тщательно тестируется под 2-3 целевые платформы и дальнейшей защите подлежит именно это ядро. Всё прочее можно и нужно открывать. Кстати как правило это самое «всё прочее» - большая часть проекта и в том или ином виде у всех повторяется, прятать его просто незачем.

п3 - закрытие исходников полнейшая глупость. «при разработке мер по противодействию злоумышленнику, предполагается что тот обладает знаниями о системе на уровне её исходных текстов» (по памяти - из рекомендаций по безопасности) То есть скрывая исходный код вы ставите своего пользователя в заведомо проигрышную позицию по отношению к вредителю. Откройте код, распространяйте бинарники и дайте средство для их валидации.

до п4, включительно - нанимайте компанию, ассоциацию или ещё кого, которые будут делать нарушителям всякие нехорошести

с п5 и далее - даже необсуждается.

ИТОГО : выделяете ядро которое стоит закрывать, покрываете его тестами, решаете как оно взаимодействует со всем остальным, выбираете целевые платформы, собираете и тестируете его на ферме (есть такая платная услуга - компиляция/сборка ПО и прогон тестов на разных платформах). В бинарном виде проект полностью предоставляете для пары стабильных платформ (RedHat|Debian), для всех прочих - бинарное ядро и исходники для самостоятельной сборки.

А 7 почему не обсуждается?
Как действовать?

>Неужели они с тех пор не успели сломать c++ abi?

libstdc++ все равно с собой тащить придется