Одно из решений - тащить с собой рядом libstdc++.so.6 и подкладывать ее в папку, которая потом указывается в LD_LIBRARY_PATH

Норм вариант.

Вопрос - можно ли собрать софтину (gcc 7.1, c++17) таким образом, чтобы она работала на altlinux 7, astra 1.5, ubuntu 16 и всем таком подобном без каких-либо дополнительных библиотек.

Можно.

Вот как делают в яндексе: https://youtu.be/Z7WuUhPJ-cU?t=3789

Спасибо

-static-libstdc++

Вопрос - можно ли собрать софтину (gcc 7.1, c++17) таким образом, чтобы она работала на altlinux 7, astra 1.5, ubuntu 16 и всем таком подобном без каких-либо дополнительных библиотек. Разработчик уверяетб что это невозможно

Невозможно??? Вон из профессии! (ну в смысле он) И софта собранного про редхатину работающий где угодно - примеров не мало

И как запустить стандарт 17 года на системе 16 года? Запустить виртуальную машину времени?

Для таких как ты специально придумали докер.

Java-разработчики смотрят на это с улыбкой и недоумением.

Для справки: код, написанный для Java 1.6, например, вполне можно запустить на JRE 1.4.

которая потом указывается в LD_LIBRARY_PATH

Можно через rpath.

мягко говоря, не устраивает.

Это вполне решение, если надо. AppImage так и делают, только аккуратнее (используется системная версия, если с ней будет работать).

Более удобным вариантом может быть взять старый дистрибутив, собрать в нём новый компилятор и линковать стандартную библиотеку статически. Сборка на старой системе нужна для старой libc, в том ютуб-видео какая-то жесть. Хотя и дистрибутив может быть не нужен, если просто поставить тулчейн (забыл название, какой-то от Red Hat что ли был).

Java-разработчики

Типичный ответ регистранта лора: «не ту проблему решаешь, смотри как надо решать мою выдуманную проблему»

т.е. стандарт разработали в первые месяцы 17-го года? Окей. А сам компилятор из исходников не соберется на дистре 16-го года?

Оставайся на линии. Нам это очень важно.

7 альт уже давно без поддержки, возни много, ну и «уверяет, что это невозможно»…

libstdc++.so.6 и подкладывать ее в папку, которая потом указывается в LD_LIBRARY_PATH

ну я так в 7 альте запускаю последний фаерфокс-esr…

сделай в запускающем скрипте - проверку, если системная старая, то юзать ту что через LD_LIBRARY_PATH

И как запустить стандарт 17 года на системе 16 года?

Чего запустить!?

А сам компилятор из исходников не соберется на дистре 16-го года?

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

Совместимость ABI же как всегда сломали. Зато можно переписывать код вечно и получать заплату...

Нет, это значит «смотри как другие сделали по уму и учись у них».

Вопрос - можно ли собрать софтину (gcc 7.1, c++17) таким образом, чтобы она работала на altlinux 7, astra 1.5, ubuntu 16 и всем таком подобном без каких-либо дополнительных библиотек. Разработчик уверяет, что это невозможно.

если новых возможностей не использовано, то можно и это не очень сложно. Если использованы, то их надо выдрать откуда-нить (обычно берут musl для сей, а чего берут для с++ я даже хз) и вкорячить в свой проект перед libstdc++. Но это достаточно геморрно, если заранее с самого начала такими вещами не озадачиваться. Так что я разраба понимаю.

Еще один, неумеющий читать.

Как запустить программу, собранную с использованием стандарта с++17 на старой системе со старым libstdc++, который не имеет понятия про стандарт с++17?

Для справки: код, написанный для Java 1.6, например, вполне можно запустить на JRE 1.4.

В данной проблеме не так. Программа написана для java 1.6 и его надо запустить на 1.4. Можно скомпилировать с байткодом 1.4, но это не шибко поможет так как использовано куча библиотек для 1.6, использовано куча методов, которых нет в 1.4. Так что, если нет изначального требования на 1.4, и разработка шла на 1.6, то хрен ты чего запустишь на 1.4. Один в один с проблемой топикстартера.

И это для меня актуально, так как я меня в поддержке проект на 1.4.2 и когда я принимаю код от других, то выкашиваю кучу String.contains и т.п. методоффф.

Как запустить программу, собранную с использованием стандарта с++17

Это стандарт языка высокого уровня, а не получившегося бинарника.

на старой системе со старым libstdc++

Написанное на c++11, но собранное с новым libstdc++, точно так же может не заработать. Версия стандарта c++ тут не при чём.

а не получившегося бинарника.

И тут приходит понимание, что стандарт С++ вообще не регламентирует с++abi.

точно так же может не заработать

Поэтому приходится гадать «может - не может».

Ты уж определись - может или не может.

Вы что такие тупые, сказала же запускай в контейнере и не парься.

Ты уж определись - может или не может.

Я тебе уже написал вроде, что ты зря упоминаешь c++NN в контексте этого вопроса. Что непонятно?

запускай в контейнере

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

ты зря упоминаешь c++NN в контексте этого вопроса.

Прям таки зря требовать возможность запуска с++17 в системе от 2014 года. Логично же требовать прямую совместимость, хрен с ней обратной.

Запустить контейнер на старых дистрах, возможно, та ещё задача.

https://docs.docker.com/engine/install/ubuntu/

Ubuntu Xenial 16.04

Прям таки зря требовать возможность запуска с++17 в системе от 2014 года

Блин. Нет никакого c++17 в бинарнике. Понимаешь? Во, качни телеграм с их сайта, а не из репозитория, и запусти. А он без поддержки c++20 не собирается.

Нет никакого c++17 в бинарнике.

Хитро ты решаешь экзистенциальные проблемы - «нет того, что есть».

Может быть, потому что -static-libstdc++? Потому что злосчастный с++17 запихали в сам бинарник?

Плюсую.

Вот как делают в яндексе: https://youtu.be/Z7WuUhPJ-cU?t=3789

Да, можно. Да, там процесс описан нормально.

Да, реализацию стандарта должен поддерживать и компиль и должна быть поддержка тех же специфичных для стандарта типов данных (типа std::any, например) в библиотеке libstdc++.

Для ТС Тогда в коде надо чтобы было типа так (можно и по-другому, чисто пример показываю):

#if __cplusplus >= 201703L
#include <any>
#endif

Это мы задействовали core language features, т.е., то, что Вы передаёте компилятору как пожелание типа –std=c++17.

Теперь прилинковываем как статические библиотеки libstdc++ может ещё и libstdc++fs понадобиться, если у Вас использованы возможности поддержки file system, это мы задействуем именно library features.

И про core language features и про library features справочник есть тут – https://en.cppreference.com/w/cpp/compiler_support. Если С++ часто и разных версий стандарта, то рекомендую держать в закладках.

И да, морально готовьтесь к тому, что бинарь будет ну очень большого размера.

Для теста разверните в виртуалочки требуемые версии линуксов, да затестите. Это не долго.И всё должно завестись.

Может быть, может не быть.

Во, качни телеграм с их сайта, а не из репозитория, и запусти. А он без поддержки c++20 не собирается.

Всё зависит от того, какие возможности стандарта были использованы. Если там только для компиля инструкции, без поддержки их в библиотеке (см. мой коммент про core language/library features чуть выше), то вполне можно обойтись и без статической компиляции линковки, пардон, соответствующей libstdc++. Иначе нет, придётся линковать статически.

Дожили, блин. 2021 год. В линуксе до сих пор проблема софт установить.

ТС, запакуй свою срань в AppImage и запускай где тебе влезет.

Вопрос - можно ли собрать софтину (gcc 7.1, c++17) таким образом, чтобы она работала на altlinux 7, astra 1.5, ubuntu 16 и всем таком подобном без каких-либо дополнительных библиотек. Разработчик уверяет, что это невозможно.

Если в этих дистрах библиотеки c++ бинарно несовместимы, то нет. Можно использовать docker контейнер или собрать прогу на каждой машине.

Вопрос - можно ли собрать софтину (gcc 7.1, c++17) таким образом, чтобы она работала на altlinux 7, astra 1.5, ubuntu 16 и всем таком подобном без каких-либо дополнительных библиотек. Разработчик уверяет, что это невозможно.

Вообще, glibc завязан на ядро. Ну если более современное ядро подсунуть, то почему бы и нет? См. https://unix.stackexchange.com/a/430462

У меня не все AppImage запускаются.

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

+1

appimage можно запустить в gdb: gdb ./program.appimage - r - bt

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

Мне и так понятно, какие то там библиотеки не той версии.