R>насколько я помню это бывает когда пытаются к примеру либу собранную для одной архитектуры, подцепить в таргету на другой архитектуре
R>к примеру R>либа собрана для x64 R>а цепляем ее к приложению которое собирается для x32
... и тогда вылезает другой unresolved: `R_X86_64_32`, но это не мой случай (а их вона сколько).
все собрано одним компилятором под 64бита.
слишком мало информации о проблеме
с исходников собирается и либа и таргет ? в один заход ? или либа тянется уже готовая собранная откуда то ?
компилер гцц ? может попробовать на другой ОС с другим компилером ? другой версией компилера ?
закинуть либу в дизассемблер и посмотреть на символ на который ругается
итд
в таких тонких ошибках может разобраться только сам компилирующий у кого есть доступ к среде
ok, в дополнение к тому что уже сказано на SO
R>с исходников собирается и либа и таргет ?
boost собран в RPMку тем же toolchain'ом (DTS-7).
R> в один заход ?
не суть важно. главное что один и тот же компилятор используется для boost'a и моего приложения (юнит тесты в данном случае)
R> или либа тянется уже готовая собранная откуда то ?
собранный boost был поставлен из RPMко в docker образ (где уже имеется DTS-7)
R>компилер гцц ?
7.2.1 (из DTS-7)
R> может попробовать на другой ОС с другим компилером ? другой версией компилера ?
можно. но нужно именоо эту комбинацию (DTS-7).
в DTS-4 (GCC 5.3.1) с бустом собранным DTSным компилятором из той же RPM spec'и подобной проблемы нет %(
R>закинуть либу в дизассемблер и посмотреть на символ на который ругается
`nm -D` и `readelf` на libstdc++.so.6.0.19 показывают что символ `_ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4` есть и экспортируется (`T`)
R>итд R>в таких тонких ошибках может разобраться только сам компилирующий у кого есть доступ к среде
поэтому и прошу помощи, ибо не понимаю WTF (пока только догадки, проверить которые иногда никак)