Непонятная зависимость libstdc++

у тебя версии glibc отличаются на тачках. Если не хочешь себе проблем то собирай пакеты в том же окружении что и на целевой тачке.

libstdc++
GLIBC_ как раз в порядке

у вас на целевой машине очень старый gcc стоит, с очень старой libstdc++
варианта 3:

1) собираете все на целевой машине, старым gcc
2) обновляете libstdc++ на целевой машине
3) собираете на своей машине, старым GCC (3.4.6)

4й вариант - линкуете libstdc++ статически

objdump -T cgiMight | grep '3.4.9'
00000000 DF *UND*   00000000 GLIBCXX_3.4.9 _ZNSo9_M_insertImEERSoT_
00000000 DF *UND*   00000000 GLIBCXX_3.4.9 _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_i

1236 ~ # objdump -T cgiMight | grep '3.4.11'
00000000 DF *UND*   00000000 GLIBCXX_3.4.11 _ZNKSt5ctypeIcE13_M_widen_initEv

У меня на целевой машине стоит Gentoo hardened, вот еще с одной машины c «не очень» старым gcc:

./prsr: /usr/lib/gcc/i486-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./prsr)
   linux-gate.so.1 => (0x4a026000)
   libdl.so.2 => /lib/libdl.so.2 (0x4a01d000)
   libstdc++.so.6 => /usr/lib/gcc/i486-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x49f31000)
   libm.so.6 => /lib/libm.so.6 (0x49f0b000)
   libc.so.6 => /lib/libc.so.6 (0x49dc8000)
   /lib/ld-linux.so.2 (0x4a027000)
   libgcc_s.so.1 => /usr/lib/gcc/i486-pc-linux-gnu/4.3.4/libgcc_s.so.1 (0x49dba000)

еще вам (и не только вам) справочная таблица версий символов GLIBCXX
для libstdc++.so.6 (GCC более старые чем 3.4.x использовали libstdc++.so.5 и их ABI несовместим)

3.4.6 (базовая версия), только GLIBCXX_FORCE_NEW (libstdc++.so.6.0.3)


4.1: (libstdc++.so.6.0.8)
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
CXXABI_1.3
CXXABI_1.3.1

4.2: те же что и 4.1 ( 6.0.9 )
GLIBCXX_3.4.9

4.3 ( 6.0.10 )
GLIBCXX_3.4.10
CXXABI_1.3.2

4.4.2: (6.0.13)
CXXABI_1.3.3
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13

4.5pre: (6.0.14)
CXXABI_1.3.4
GLIBCXX_3.4.14


вывод - вы собираете GCC 4.4 ) и хотите запустить на машине с GCC 3.4.x )
Самый простой вариант взять libstdc++.so.6.0.13 от вашего 4.4 и закинуть в /usr/local/lib на целевой машине, сделать ldconfig

Да, это все понятно. Но я повторю вопрос: Что могло в коде спровоцировать эту зависимость???? Это все собиралось gcc 4.4 и запускалось на целевых машинах без всяких проблем, еще два дня назад. Единственно что за эти два дня изменилось сам код!

1236 ~ # objdump -T cgiMight | grep '3.4.11'
00000000 DF *UND*   00000000 GLIBCXX_3.4.11 _ZNKSt5ctypeIcE13_M_widen_initEv


сами ж себе уже и ответили, название функции конечно mangled, но в коде появился вызов этого, соответственно компоновка была произведена либо с единственной версией этой функции, либо с наивысшей доступной в libstdc++ для вашего GCC 4.4

Единственно что за эти два дня изменилось сам код!

Смотрите чейнджлоги вашего кода и сверяйте с чейнджлогами libstdc++. Вероятно использовался какой-то нестандартный прием в вашем коде. Отсюда и разрыв совместимости.

Круто, спасибо! Только я понятия не имею что это за mangled? И как Вы поняли что это она? я вижу только _ZNKSt5ctypeIcE13_M_widen_initEv

про mangling почитаете тут http://en.wikipedia.org/wiki/Name_mangling
если коротко - имена функций сокращаются заменяясь частично хешем.

вообщем что то в вашем коде или явно (сами написали) или опосредовано через другую функцию вызывает *ctype*widen*init*

А лучше не мучайтесь и поставьте libstdc++.so.6.0.13 на целевую машину в /usr/local/lib , или собирайте старым компилятором, или линкуйте статически libstdc++.a

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

ИМХО лучший способ - пересобрать код на целевой машине.

Круто, спасибо! Только я понятия не имею что это за mangled? И как Вы поняли что это она? я вижу только _ZNKSt5ctypeIcE13_M_widen_initEv

$ man objdump | grep -demangle

м, спасибо, теперь буду знать как деманглить имена функций )

м, спасибо, теперь буду знать как деманглить имена функций )

{nm | objdump} --demangle

Просто очень сомневаюсь, что в libstdc++ так быстро умудрились сломать что-то стандартное.

Спасибо. Познавательно.

Не знаю как это назвать!!!! Решил, выяснить откуда берется зависимость. Перекомпилил вручную весь проект, зависимости от этих либ нет!!!! Код на целевой машине работает!

Полтергейст...