См. описание бага по ссылке, такая же ошибка воспроизводится при пересборке пакета castxml с помощью clang/llvm: [ 54%] Linking CXX executable ../bin/castxml /usr/lib64/libclangFrontend.a: error adding symbols: File format not recognized clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [src/CMakeFiles/castxml.dir/build.make:210: bin/castxml] Error 1 Есть еще баг в debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767323, где опять же говорится, что такие ошибки это проблема ld, а не сборки clang/llvm.
(In reply to comment #0) > См. описание бага по ссылке, такая же ошибка воспроизводится при пересборке > пакета castxml с помощью clang/llvm: > > [ 54%] Linking CXX executable ../bin/castxml > /usr/lib64/libclangFrontend.a: error adding symbols: File format not > recognized В какой версии GNU ld или GNU gold поддерживается этот формат объектных файлов, которые производит clang/lld? Есть ли основания полагать, что такая поддержка вообще будет реализована? GNU и LLVM - это разные экосистемы. Я полагаю, что при сохранении нынешних тенденций развития GNU и LLVM совместимость между ними будет неуклонно снижаться.
(In reply to comment #1) > (In reply to comment #0) > > См. описание бага по ссылке, такая же ошибка воспроизводится при пересборке > > пакета castxml с помощью clang/llvm: > > > > [ 54%] Linking CXX executable ../bin/castxml > > /usr/lib64/libclangFrontend.a: error adding symbols: File format not > > recognized > > В какой версии GNU ld или GNU gold поддерживается этот формат объектных файлов, > которые производит clang/lld? Есть ли основания полагать, что такая поддержка > вообще будет реализована? Мне кажется, тут все даже интереснее: https://svn.boost.org/trac10/ticket/12565 > Explicityly passing linkflags="-plugin /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/LLVMgold.so" fixes this. Я попробую проверить это в нашей ситуации. > > GNU и LLVM - это разные экосистемы. Я полагаю, что при сохранении нынешних > тенденций развития GNU и LLVM совместимость между ними будет неуклонно > снижаться. Тогда нужно принять решение, мы планируем параллельную поддержку этих экосистем или нет. Иначе придется продолжать собирать llvm в режиме совместимости с gcc и без clang в ущерб возможностей и производительности.
(In reply to comment #2) > Мне кажется, тут все даже интереснее: > https://svn.boost.org/trac10/ticket/12565 > > > Explicityly passing linkflags="-plugin /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/LLVMgold.so" fixes this. > > Я попробую проверить это в нашей ситуации. Это очень правдоподобный рецепт. > > GNU и LLVM - это разные экосистемы. Я полагаю, что при сохранении нынешних > > тенденций развития GNU и LLVM совместимость между ними будет неуклонно > > снижаться. > Тогда нужно принять решение, мы планируем параллельную поддержку этих экосистем > или нет. Иначе придется продолжать собирать llvm в режиме совместимости с gcc и > без clang в ущерб возможностей и производительности. Да, но хотелось бы делать информированный выбор.
(In reply to comment #3) <skip> > > > GNU и LLVM - это разные экосистемы. Я полагаю, что при сохранении нынешних > > > тенденций развития GNU и LLVM совместимость между ними будет неуклонно > > > снижаться. > > Тогда нужно принять решение, мы планируем параллельную поддержку этих экосистем > > или нет. Иначе придется продолжать собирать llvm в режиме совместимости с gcc и > > без clang в ущерб возможностей и производительности. > > Да, но хотелось бы делать информированный выбор. Пока выбор очень прост - переходить на llvm везде, где требуется llvm. Например, castxml собрался при замене ld на lld. Но в этом случае получается несовместимость по сборочным флагам и опциям, поскольку я никак не стремился к gcc.
*** Bug 35018 has been marked as a duplicate of this bug. ***
По результатам сборки bcc, предлагаю вернуть совместимость статических libclang и libLLVM с GNU ld.
(In reply to comment #6) > По результатам сборки bcc, предлагаю вернуть совместимость статических libclang > и libLLVM с GNU ld. Я не понимаю, почему это баг на binutils.
