Здравствуйте, zaufi, Вы писали:

Z>очень хочу понять WTF наконец..

вот такой код нагуглился: https://github.com/cloudera/Impala/commit/b18aa84dfb3162baf2311a59c79934d2f952c397#diff-af3b638bc2a3e6c650974192a53c7291
начинал отсюда: http://community.cloudera.com/t5/Interactive-Short-cycle-SQL/UDF-Problem-unresolvable-relocation-of-ZNSs4-Rep20-S-empty-rep/m-p/56741
пришел сюда: https://github.com/cloudera/Impala/commit/f174a759547aa032959f2e90dbeb33bcac0f8ec2#diff-e3f5bb54277bb6fe044afe87af0beed2

попробуй расковырять, как они зафиксили

ps. у тебя тесты являются исполняемым файлом или .so?

Hi all,

в очередной раз столкнулся с проблемой, обойти которую "простым обновлением до более новых binutils" не получается.
сама проблема описана на StackOverflow: https://stackoverflow.com/questions/48706962/unresolvable-r-x86-64-none-relocation

если кто-то может что-то ответить вразумительное, баунти с меня (в т.ч. и тут %)
очень хочу понять WTF наконец..

насколько я помню это бывает когда пытаются к примеру либу собранную для одной архитектуры, подцепить в таргету на другой архитектуре

к примеру
либа собрана для x64
а цепляем ее к приложению которое собирается для x32

Здравствуйте, reversecode, Вы писали:


R>насколько я помню это бывает когда пытаются к примеру либу собранную для одной архитектуры, подцепить в таргету на другой архитектуре

R>к примеру
R>либа собрана для x64
R>а цепляем ее к приложению которое собирается для x32

... и тогда вылезает другой unresolved: `R_X86_64_32`, но это не мой случай (а их вона сколько).
все собрано одним компилятором под 64бита.

слишком мало информации о проблеме
с исходников собирается и либа и таргет ? в один заход ? или либа тянется уже готовая собранная откуда то ?
компилер гцц ? может попробовать на другой ОС с другим компилером ? другой версией компилера ?

закинуть либу в дизассемблер и посмотреть на символ на который ругается
итд
в таких тонких ошибках может разобраться только сам компилирующий у кого есть доступ к среде

Здравствуйте, reversecode, Вы писали:


R>слишком мало информации о проблеме

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 (пока только догадки, проверить которые иногда никак)

Здравствуйте, uzhas, Вы писали:


U>попробуй расковырять, как они зафиксили

спасибо, щаз повтыкаю...

U>ps. у тебя тесты являются исполняемым файлом или .so?

исполняемым файлом