LINUX.ORG.RU

Использование GCC разных версий при сборке библиотек, C++.

 , , , ,


1

2

Имеем ситуацию. Есть «тулкит» образца ~2006г. в составе имеет gcc-3.3.3, gdb-6.5, uclibc и binutils тех же времён... И включает он в себя ряд .so библиотек и программу. А моя задача дополнить это всё своей .so.

И имеем современное готовое ПО в исходниках, на C++, достаточно большого объёма и сложности, чтоб там не было желания что-то менять или отлаживать. Проблема в том, что похоже с gcc-3.3.3 оно не работает — ещё на этапе сборки натыкался на сбои в GCC, но обошёл, но после запуска тоже есть странности. Тем более, что взгляд на багтрекер для gcc-3.3.3 вызывает суицидальные настроения.

Вопрос. Можно ли взять более новую современную версию gcc и попросту пересобрать с теми же настройками (configure имеется ввиду) и начать использовать? Какие контраргументы?

Во-первых практический результат для gcc-4.8.4 (пересобрал gcc и binutils). Есть две программы: одна после этого даже не стартует. Валится в фиг знает где, gdb показывает полную чушь и попорченный стек. Вторая (маленькая, тест) стартует и даже как-то работает. Но gdb не показывает стек (bt) нормально, только пару-тройку функций сверху.

Во-вторых размышления на тему какие могут быть проблемы:

1) несовместимость ABI. Здесь (https://gcc.gnu.org/onlinedocs/libstdc /manual/abi.html) пунктом три приводятся версии libstdc++ для gcc и даны комментарии о несовместимости. В частности, для gcc-3.3.3 должно быть libstdc++.so.5 Практически у программы слинкованной gcc-4.8.4 есть зависимость тоже от libstdc++.so.5 (странно... хотя выше я пишу C++, но стандартная C++ библиотека вообще не используется — всё своё).

2) не знаю что ещё, надеюсь мне тут подскажут.

И, наконец, как быть. Использовать gcc-3.3.6 ? Кажется разумным вариантом. Но в имеющемся ПО дикий фарш из C++ кода и темплейтов, хоть формально всё и c++03, но судя по всему чем-то младше gcc-4.x никогда и не собиралось и не факт, что заработает. Хотелось бы потому gcc-4.x.

Платформа не x86, ежели что. Linux embedded, mips. Ядро и uclibc даны свыше (как и всё остальное), хидеров от ядра нет (uclibc пересобрать тоже сложно, но наверное можно, и вообще хотелось бы — но, насколько я понимая это вообще бессмысленно, ввиду несовместимости разных версий uclibc между собой).


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

Причём здесь chroot? Речь про кросс-компиляцию в условиях, когда вся система собрана gcc-3.3.3, а я хочу в неё добавить .so-шник собранный gcc-4.8.4.

fk0
() автор топика

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

CYB3R ★★★★★
()

Валится в фиг знает где, gdb показывает полную чушь и попорченный стек.

Valgring вам в помощь.

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