(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.