LINUX.ORG.RU

C++ UDF

 , ,


2

3

Добрый день.

Скомпилил динамическую библиотеку на Ubuntu, с gcc = 7.4.0.

Далее запускаю библиотеку на RHEL 7, где gcc 4.8.5

Выдает следующую ошибку:

ERROR: AnalysisException: Could not load binary: /user/impala/udfs/libudfcrypto.so Unable to load /var/lib/impala/udfs/libudfcrypto.669611.10.so dlerror: /opt/cloudera/parcels/CDH-5.15.1-1.cdh5.15.1.p0.4/lib/impala/lib/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /var/lib/impala/udfs/libudfcrypto.669611.10.so)

Подскажите, пожалуйста, каким образом можно её решить. На Ubuntu надо будет установить более старую версию gcc, как там где осуществляется запуск?

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

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

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от MacJei

Наверное проще всего будет заюзать для сборки 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
alx777 ()
Ответ на: комментарий от dvetutnev

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

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

Serral ()
Ответ на: комментарий от dvetutnev

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

Serral ()
Ответ на: комментарий от Serral

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

pon4ik ★★★★★ ()
Ответ на: комментарий от dvetutnev

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от dvetutnev

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

В целом: ++

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

Stil ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

Serral ()
Ответ на: комментарий от Serral

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

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

Stil ★★★★★ ()
Ответ на: комментарий от Serral

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

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

Stil ★★★★★ ()
Ответ на: комментарий от UVV

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

pon4ik ★★★★★ ()
Ответ на: комментарий от Stil

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

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

Serral ()
Ответ на: комментарий от Serral

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

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

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

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

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

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

Serral ()