А windows для решения проблемы в VS есть комбобокс, в котором можно выбрать рантайм совместимый с WinXP. и больше ничего не нужно. А для всех версий новее, чем XP вообще ничего делать не нужно, разве что указать константу препроцессора с минимальной версией windows.
Это — удобно и понятно. Извращаться с кросскомпиляцией только для того, чтобы подлинковать старый glibc — это неудобно.
Это вы не верно транслируете суть. DirectX12 — это неотъемлемая часть системы. А сишный рантайм — это всего лишь сишный рантайм. И проблема линукса как раз в том, что сишный рантайм вшит в систему довольно прочно и глубоко. Это создает массу неудобств не только разработчикам но и конечным пользователям
Мы приходим к тому, что я изначально написал выше. При возникновении проблем с зависимостями в Windows они решаются простым копированим потребных dll. При возникновении проблем с зависимостями в linux возникает необходимость перекомпиляций.
Я имею ввиду, что под windows я могу компилировать свой проект и линковать чужие dll не вникая в их зависимости — мой проект скомпилируется и слинкуется.
Так я и собираю свою программу со старым glibc 2.13. Но у меня есть third-party либа собранная под убунтой и glibc 2.23 и вот оно-то и источник головняка.
Фактически вы перекладываете проблему совместимости на конечного пользователя. Но это не значит, что она пропадает.
Я так сделать не могу, т.к. софт штучный и пишется под ТЗ конкретного заказчика. Т.е. первое, что я спрашиваю, это под какую платформу нужен продукт.
Можно. Только это и есть неудобство и потенциальный источник проблем. Я в конечном итоге так и делал, т.к. деваться было некуда.
А теперь смотрите. Кастомер почитал хабр и понял, что нужно мигрировать с centos 6 на centos 7 или даже на 8. Обновляется, копирует прогу — она падает, т.к. наша приватная glibc была собрана для другого ядра. И хорошо, если просто падает. А если начинает тихонько глючить это вообще беда.
Нельзя взять из убунты. glibc из убунты на centos не будет работать, потому как ядра разные. Добро пожаловать в суровый мир linux.
Я собирал свою glibc из исходников и прикладывал в локальной папке.
Но это 1. потребовало много усилий. 2. это тоже небезопасный способ, т.к. glibc завязано на ядро, а процесс смены ядра я никак не контролирую. При первой же возможности я от этого зоопарка избавился посредством смены кодека. Но с костылем пришлось жить несколько лет.
Если вам очень дорог клиент, то вы можете конечно выпустить ПО именно под его окружение, но это совсем другая история.
Я и пытаюсь донести, что разработка коммерческого софта под linux — это почти всё время какая-то «другая история». Вместо решения задач предметной области приходится тратить много ресурсов на преодоление побочек от unix way.
Vista SP2 - поддерживается.
Дык. Он не только с семеркой совместим, но и с более старой вистой.
www.microsoft.com/en-us/download/details.aspx?id=48234
Это — удобно и понятно. Извращаться с кросскомпиляцией только для того, чтобы подлинковать старый glibc — это неудобно.
Есть всякого рода хаки типа
stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version
но это все очень сильно снижает надежность разработки и просто еще более неудобно, чем просто компилять в старом linux.
Это, значит, что среда разработки под linux должна жить в бородатой системе с kernel 2.6.27 и GLIBC 2.17.
А под windows их разработчик вполне может сидеть на свежей Win10, никаких проблем с запуском приложения под Win7 у него не будет.
TeamViewer for Linux requires a Linux 2.6.27 kernel and GLIBC 2.17
То там пишут
The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected.
То есть может, оно будет работать, может нет — никто ничего не обещает.
Я так сделать не могу, т.к. софт штучный и пишется под ТЗ конкретного заказчика. Т.е. первое, что я спрашиваю, это под какую платформу нужен продукт.
А теперь смотрите. Кастомер почитал хабр и понял, что нужно мигрировать с centos 6 на centos 7 или даже на 8. Обновляется, копирует прогу — она падает, т.к. наша приватная glibc была собрана для другого ядра. И хорошо, если просто падает. А если начинает тихонько глючить это вообще беда.
Я собирал свою glibc из исходников и прикладывал в локальной папке.
Но это 1. потребовало много усилий. 2. это тоже небезопасный способ, т.к. glibc завязано на ядро, а процесс смены ядра я никак не контролирую. При первой же возможности я от этого зоопарка избавился посредством смены кодека. Но с костылем пришлось жить несколько лет.
Я и пытаюсь донести, что разработка коммерческого софта под linux — это почти всё время какая-то «другая история». Вместо решения задач предметной области приходится тратить много ресурсов на преодоление побочек от unix way.