LINUX.ORG.RU

Согласование версии компилятора для кода и линкуемой библиотеки?

 ,


0

1

Есть библиотека (набор хидеров и скомпилированных .cpp файлов из которых собран libXXX.a-файл). Есть приложение которое эту библиотеку использует (хидеры инклюдит, libXXX.a линкует).

Вопрос - как обеспечить/проконтролировать согласование версий компилятора, которым собирается приложение и libXXX.a? Потому что скажем обновили компилятор, библиотеку пересобрать (по совершенно разным причинам) забыли - приложение компилируется но крэшиться, пользователи пугаются. Библиотека может быть как установлена в системе, так и стоять локально у пользователя.

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

Интересует в первую очередь решение для gcc, но в идеале хотелось бы чего то универсального.

★★★★

Ответ на: комментарий от JacobTwoTwo

C++11. Оно таки есть, скажем в библиотеке std::shared_ptr собранный gcc-4.8, код собран gcc-6, дает сегфолт или что то вроде того.

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

C++

Да, названия функций в объектниках могут меняться. Почему-то никто не стал регламентировать это дело.

Вопрос - как обеспечить/проконтролировать согласование версий компилятора

Make all? Напишите большой Makefile, который будет содержать в том числе и библиотеки.
В общем случае единственный способ обеспечить незабывание чего-то — автоматизация этого чего-то.

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

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

Если библиотека установлена в системе глобально, это не поможет - у юзера не хватит прав (отдельная история как это решать).

Можно ли как то узнать каким компилятором был собран объектник?

AntonI ★★★★
() автор топика

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от AntonI

Если перед тобой стоит такой вопрос, значит ты решительно делаешь что-то не так, подумай об этом. Иначе как бы работали крупные программные пакеты на произвольных машинах пользователя? Представь какой был бы это ад.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Я наверняка делаю что то не так, только не очень понимаю что.

Но есть нюанс - в данной проблеме библиотека НЕ изменилась, изменился компилятор. Каким образом тут поможет версия библиотеки - ума не приложу...

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

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

Хотя тут я согласен с товарищем JacobTwoTwo - если либонька своя с доступными сорсиками, то лучше ее и компилять в одной связке с прогой.

I-Love-Microsoft ★★★★★
()

Интересует в первую очередь решение для gcc, но в идеале хотелось бы чего то универсального.

никакого универсального решения нет. коммерческий софт собирается той же версией компилятора, которой собирали библиотеки. кресто-проблемы.

waker ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Если библиотека собрана GCC 4.x а программа GCC 6.x, то будет ли проблема?

Смотря какой там GCC 4, я помню у меня когда-то были сегфолты, когда приложение было собрано новым GCC, а все либы в системе — старым. И даже на винде такое было. Обновил MinGW с 4.x до 4.5.x, тогда как официальные сборки Qt под винду были собраны каким-то старым MinGW, в итоге абсолютно все приложения начали непонятным образом сегфолтиться.

P.S. ТС, может вот это: https://github.com/lvc/abi-compliance-checker

Как-то облегчит боль.

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

Спасибо. С-но мне наверное проще вязаться к версии компайлера а не версии ABI - проще и надежней будет?

Я чуть уточню (усложню) задачу - на одной машине может быть несколько компайлеров, нужно при линковке подсовывать нужный вариант libXXX.a (собранный нужным компайлером), и на лету собирать нужный вариант если его нету. Если либа стоит глобально, то каждый юзер может собрать себе локально нужный вариант libXXX.a (опять таки на лету). Еще все это хозяйство нужно обновлять при обновлении самой либы.

Собственно вопрос как это сделать прямо, свелосипедить то на основе gnumake я че то могу и сам;-) Ну там писать в какой нить файлик версию компайлера по умолчанию, писать версию компайлера в имя libXXX.a и прочие извращения...

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

если библиотека собрана более старой версией g++, чем приложение, то все должно работать, пока не сломают ABI.

waker ★★★★★
()

Велкам ту СиПласПлас.

Ответ: никак.

У C++ нет ABI. Соответственно, не выставляй C++ наружу из библиотеки.

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

Есть соглашения о вызовах и тому подобное что является ABI, может в этом дело? Да тут вобще интересно просто глянуть на пусть даже бинарные дифы рабочей библиотеки и той с которой вылетает всё. Дабы понять что и почему так происходит, а не гадать.

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

Какие соглашения о вызовах? У C++ в принципе нет ABI, у тебя между минорными версиями компилятора может измениться даже то, где и как доставать vtable, грубо говоря, не то что что-то еще.

Просто не надо выставлять C++ наружу. А лучше вообще его не использовать.

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

Какие соглашения о вызовах?

Хз, например __fastcall какой нибудь прописан.

А лучше вообще его не использовать.

:D согласен

Dron ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.