C++ UDF

Если коротко, то собрать своё поделие на RHEL 7. gcc тут не причём, у тебя версия libstdc++ другая на системе.

Если не так коротко - тебе нужно собрать тулчейн, в котором libstdc++ имеет версию ABI ту же или ниже чем на целевой платформе, и собирать им. Т.е. да - поставить другую версию gcc, но в пакетах её может и не оказаться.

А что бы два раза не ходить, и версию ABI glibc стоит ограничить.

Спасибо большое. Буду пробовать.

Наверное проще всего будет заюзать для сборки docker с соответствующим образом

docker run -it fedora:23 /bin/bash

# yum update
# yum -y install gcc gcc-c++ make
# g++ --version
g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
# strings /lib64/libstdc++.so.6|grep CXXABI
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_1.3.8
CXXABI_1.3.9

Спасибо

Спасибо вам большое. Попробую, надеюсь получится.

Можно таскать с приложением нужную версию libstdc++. Разумеется не забывая про очередность путей для поиска библиотек (например используя RPATH=$ORIGIN).

Можно таскать с приложением нужную версию libstdc+

Новая версия libstdc++ требует новую версию libc. Наиболее правильное решение - сделать себе окружение для билда из старого debian/centos и в нем собираться.

Можно, но только когда понимаешь зачем. Читай если есть нефункциональные требования, ибо в функциональном плане менялось довольно мало, и свежие стандарты можно собрать под довольно древнее сишное ABI. А можно и стандарт постарше поддержать если рантайм на целевой платформе такой…

Это не правда. 14ый и 17ый стандарты точно можно собрать под ну ооочень древние сишные abi. Лет 7-10 люфта там точно есть.

Именно так у нас и сделано. Машина CentOS 6, на ней GCC 8 собранный с ABI C++11. libstdc++ от него вкладываем в дистрибутив своего софта.

есть нефункциональные требования

Например захотелось small string optimization и без copy on write.

Это не правда. 14ый и 17ый стандарты точно можно собрать под ну ооочень древние сишные abi. Лет 7-10 люфта там точно есть.

А не надо путать «можно собрать на старом окружении» и «можно собрать на новом и отдать для старого окружения». В glibc есть внутренние детали реализации, которые вылазят в линковке.

В случае плюсов всё и правда страшно, но вот либсишное ABI, там всё гораздо лучше. Почти уверен, что ты не назовёшь версию rhel в проде куда нельзя собрать gcc <9.x, в том числе и с относительно новыми плюсовыми стандартами. libstdc++ правда придётся свою таскать(или статически линковать) а вот glibc - нет.

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

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

Машина, ради сборки. Фу такими быть, вы ещё по дёдику под каждую платформу замутите. Не, конечно кто как хочет так и онанирует, но зачем, очень и очень странно и непонятно лично мне.

В случае плюсов всё и правда страшно, но вот либсишное ABI, там всё гораздо лучше. Почти уверен, что ты не назовёшь версию rhel в проде куда нельзя собрать gcc <9.x, в том числе и с относительно новыми плюсовыми стандартами. libstdc++ правда придётся свою таскать(или статически линковать) а вот glibc - нет.

В целом: ++

Только таскать лучше libc++ :)

Почти уверен, что ты не назовёшь версию rhel в проде куда нельзя собрать gcc <9.x

Мы о чем-то разном говорим. Собрать то можно, я сам gcc 9.2 из под убунты 14.04 использую. Речь о том, что тот же gcc 9.2 из убунты 19.10 создаст бинарник, который не запустится на 14.04, хоть ты клади с ним libstdc++ из той же 19.10, хоть нет.

Только таскать лучше libc++ :)

Смотря с чем. Если это библиотека, или плагин, то libc++ исключается по причине возможного конфликта с libstdc++.

О разном так это точно.

Можно собрать gcc с версией glibc той же, что и на целевой платформе. Тогда, libstdc++ бинарники будут не совместимы по abi c системной libstdc++, но вот сама libstdc++ из этого тулчейна будет отлично работать на целевой платформе. Под 5ый редхат например можно легко собрать g++ 8.x так что бы бинарники были совместимы с сишным рантаймом и таскать придётся только плюсовый рантайм, насчёт 9ого не уверен, кажется, кто-то на лоре относительно недавно плакал как раз что что-то поломали там в abi для 9.x. Со шлангом в теории всё может оказаться ещё лучше, но я им никогда не пользовался для релизных сборок, но идея та же, главное сишное abi.

Т.е. одно дело собрать всё актуальных версий, и другое дело, что версии сишного abi довольно долго остаются достаточно совместимыми для тех кто пишет портабельный код.

В смысле собрать под любым свежим дистром такой gcc, с такой же версией glibc как на целевой платформе, и бинарники(включая libstdc++), будут совместимы с целевой платформой.

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

А почему лучше?

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

а вот glibc - нет.

Хрюкнул. Есть уверенность, что ты не попадёшь в эти полпроцента? https://abi-laboratory.pro/?view=timeline&l=glibc

Есть. Но на практике адекватный софт совместим .

А как же CI/DI ?) Именно для него эта машинка используется.

Тем более для ci фу.

потому что с/под шлангом «complete toolchain» собрать проще, а шланг сильно лучше работает с libc++. Ну и бонусом можно получить (почти) одинаковые тулчейны подо всё кроме шиндоуз

Смотря с чем. Если это библиотека, или плагин, то libc++ исключается по причине возможного конфликта с libstdc++.

Таки предполагается, что если ты тащишь рантайм, то и все твои зависимости зависят от твоего рантайма

Опять хрюкнул. Я вот хз, когда там в очередной раз всё сломается =)

Хз видимо мы с разными классами продуктов работаем. Я крайне редко нарывался на проблемы именно в glibc ABI. Да каких-то символов нет, под такие случаи обычно просто сделан детект и замена этого символа. Благо их даже не сотни.

Таки предполагается, что если ты тащишь рантайм, то и все твои зависимости зависят от твоего рантайма

Таки рантайм не обязательно плюсовый изначально. Это может быть, например, софтина на смеси питона и С. Одни свое расширение с libstdc++ слинковали, вторые с libc++ - и привет креш. Потому в таких случаях лучше просто брать libstdc++ как де факто стандарт.

Ты либо контролируешь рантайм либо нет. Перечитай свой коммент и расскажи, какая разница какой из рантаймов таскать, что бы избежать описанной тобой проблемы:)

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

Перечитай свой коммент и расскажи, какая разница какой из рантаймов таскать, что бы избежать описанной тобой проблемы:)

Никакой не таскать.

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

Загрузится. Но опять же, таскать с собой в таких случаях нельзя.