есть .so, из зависимостей только glibc, x86_64. нужно чтобы программа не дергала ничего из свежих версий glibc. для этого через -include подключаю файлик с кучей строчек такого вида:
__asm__(".symver __exp_finite,exp@GLIBC_2.2.5");
__asm__(".symver __acosf_finite,acosf@GLIBC_2.2.5");
__asm__(".symver __log_finite,log@GLIBC_2.2.5");
__asm__(".symver __pow_finite,pow@GLIBC_2.2.5");
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
обычно этого достаточно, но для C++ нужно подключать libsupc++.a.
в этой либе используется memcpy, поэтому либа пропатчена, и ссылается на memcpy@GLIBC_2.2.5.
это работало до недавного времени, но я кое-что поменял в коде, и работать перестало. поменять назад нельзя, т.к. вернется серьезный баг (не имеющий отношения к проблеме).
получается вот такое:
$ readelf -Ws mylib.so | grep memcpy
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.2.5 (2)
21: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.14 (5)
201: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.2.5
296: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@@GLIBC_2.14
вобщем, в подробностях рассказывать все сложно (только по запросу), но теперь собсно мой вопрос.
можно ли как-то отследить, откуда в результирующем .so появилась ссылка на memcpy@GLIBC_2.14?
известно, что в libsupc++.a нет ссылок на memcpy, есть только memcpy@GLIBC_2.14, но в результирующем .so они появляются именно после линковки этой либы.
в .so которые не используют C++ — проблем нет.
интересует, нет ли каких-нибудь логов в gcc/g++/ld, которые помогли бы обнаружить источник этого вызова.
буду признателен за любые полезные советы.
