LINUX.ORG.RU

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


0

0

На машине где собираю программу:
ldd prsr
   linux-gate.so.1 => (0x0078f000)
   libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a84000)
   libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00347000)
   libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x008e8000)
   libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00439000)
   /lib/ld-linux.so.2 (0x0021d000)
   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x009ee000)

На целевой машине:
ldd prsr
./prsr: /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./prsr)
./prsr: /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./prsr)
   libdl.so.2 => /lib/libdl.so.2 (0x00485000)
   libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0x00132000)
   libm.so.6 => /lib/libm.so.6 (0x0060a000)
   libc.so.6 => /lib/libc.so.6 (0x00273000)
   /lib/ld-linux.so.2 (0x007ad000)
   libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 (0x00f62000)

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


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

true_admin ★★★★★ ()

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

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

Sylvia ★★★★★ ()

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

T-34 ()
Ответ на: комментарий от T-34

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

T-34 ()
Ответ на: комментарий от Sylvia

У меня на целевой машине стоит 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)

T-34 ()

еще вам (и не только вам) справочная таблица версий символов 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

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

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

T-34 ()
Ответ на: комментарий от T-34

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

Sylvia ★★★★★ ()
Ответ на: комментарий от T-34

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

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

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

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

T-34 ()
Ответ на: комментарий от T-34

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

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

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

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

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

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

ssk85 ()
Ответ на: комментарий от T-34

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

$ man objdump | grep -demangle

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

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

{nm | objdump} --demangle

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

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

ShTH ()
Ответ на: комментарий от T-34

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

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