Невозможно использовать libc ++ с clang ++ - 5.0

Я установил clang ++ - 5.0, чтобы опробовать новые возможности C ++ 17, но для полноценного использования мне нужна новая библиотека. Не сумев найти более новую версию libstdc ++, я решил попробовать libc ++.

Я проверил это, используя аналогичный способ, описанный здесь.

После проверки я скомпилировал его с помощью самого clang, так как было рекомендовано использовать clang. Компиляция прошла без проблем. Потом установил, заставил положить их в директорию /usr/local/include/c++/v1.

Когда я пытался что-то скомпилировать, я получал сообщение об ошибке, что компилятор не может найти <stddef.h>. Решил проблему с перенаправлением включений: -isystem /usr/local/include/c++/v1.

Но тогда компоновщик выдает много ошибок, связанных с исключениями и виртуальными таблицами. Понятия не имею, что делать в таком случае.

Можно ли это исправить?

Моя установка: ubuntu 16.04 LTS со всеми обновлениями, clang ++ - 5.0, cmake-3.6.

Вот мои флаги:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -v -stdlib=libc++ -Wall -Wextra -pedantic-errors -std=c++1z -isystem /usr/local/include/c++/v1")

Выдержка из сообщения об ошибке:

//usr/local/lib/libc++.so: undefined reference to `__cxa_end_catch'
//usr/local/lib/libc++.so: undefined reference to `__cxa_pure_virtual'
//usr/local/lib/libc++.so: undefined reference to `__cxa_rethrow'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'

ОБНОВЛЕНИЕ:

После сборки libc ++ abi он успешно проходит этап сборки, но теперь вылетает с ошибкой, говоря

ошибка при загрузке разделяемых библиотек: libc ++ abi.so.1: невозможно открыть файл общих объектов: нет такого файла или каталога

Текущие флаги:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -isystem /usr/local/include/c++/v1 -stdlib=libc++ -lc++abi -Wall -Wextra -pedantic-errors -std=c++1z")

Посмотрев, я обнаружил, что они отсутствуют в /usr/lib/, но присутствуют в /usr/local/lib.

Вот результат ldd program:

linux-vdso.so.1 = ›(0x00007ffd1b7da000)

libc ++ abi.so.1 = ›/usr/local/lib/libc++abi.so.1 (0x00007f69bd322000)

libc ++. so.1 = ›/usr/local/lib/libc++.so.1 (0x00007f69bcf80000)

libm.so.6 = ›/lib/x86_64-linux-gnu/libm.so.6 (0x00007f69bcc76000)

libgcc_s.so.1 = ›/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f69bca60000)

libc.so.6 = ›/lib/x86_64-linux-gnu/libc.so.6 (0x00007f69bc697000)

libpthread.so.0 = ›/lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f69bc479000)

librt.so.1 = ›/lib/x86_64-linux-gnu/librt.so.1 (0x00007f69bc271000) /lib64/ld-linux-x86-64.so.2 (0x000055e63a9a9000)


person Incomputable    schedule 08.03.2017    source источник
comment
Проблема в том, что libc++abi.so не включается во время связывания. В более новых версиях libc ++ файл libc++.so должен быть сценарием компоновщика, содержащим INPUT(-lc++abi libc++.so.1). Это то, что вы видите? Включили ли вы репозиторий libc ++ abi при сборке Clang и libc ++? Что выводит clang++ -### -v -stdlib=libc++ -xc++ /dev/null?   -  person EricWF    schedule 09.03.2017
comment
Не забудьте снова скомпилировать libc ++ abi и libc ++ в дереве LLVM. Это должно выглядеть примерно так: libcxx.llvm.org/docs/BuildingLibcxx.html # начало работы   -  person EricWF    schedule 09.03.2017
comment
Что вылетает? Вы установили libc ++ abi в /usr/local/lib, как вы это сделали с libc ++?   -  person EricWF    schedule 09.03.2017
comment
но он находит libc ++. так что в том же каталоге? Какой результат ldd <myprog>?   -  person EricWF    schedule 09.03.2017
comment
Моя цель как сопровождающего libc ++ - заставить все работать из коробки, чтобы никому не приходилось обращаться к переполнению стека. Не стесняйтесь писать сообщения сообщества, я обязательно его рассмотрю, но настоящая цель здесь - избежать ошибок и, в первую очередь, необходимости в документации.   -  person EricWF    schedule 09.03.2017
comment
Давайте продолжим это обсуждение в чате.   -  person EricWF    schedule 09.03.2017


Ответы (1)


Итак, что привело к проблеме, на самом деле я оставил часть с libc ++ abi. Большая часть процедуры описана в документации с небольшими отклонениями. .

Для меня процедура была примерно такой:

  • Касса llvm

  • Оформить заказ на libc ++ и libc ++ abi. Не забудьте проверить оба!

  • Настроить. Я не уверен, имеет ли это значение, но я построил его с конфигурацией выпуска, например указал -DCMAKE_BUILD_TYPE=Release. Также убедитесь, что он будет скомпилирован с помощью clang.

  • Установите оба. Вероятно, они будут где-то в папке /usr/local/lib/.

  • Сообщите компилятору, что вам нужен libc ++. Флаги -stdlib=libc++ -lc++abi. Если он будет жаловаться на отсутствие <stddef.h>, добавьте -isystem path/to/includes/ к флагам компилятора, что в моем случае было -isystem /usr/local/include/c++/v1.

person Community    schedule 09.03.2017
comment
›Сообщите компилятору, что вам нужен libc ++. Флаги -stdlib=libc++ -lc++abi. Если он будет жаловаться на отсутствие <stddef.h>, добавьте -isystem path/to/includes/ к флагам компилятора, который в моем случае был -isystem /usr/local/include/c++/v1. Флаги: -stdlib = libc ++ -lc ++ abi Если вы правильно построили clang / libc ++ / libc ++ abi, ни один из этих флагов не нужен, кроме -stdlib=libc++. - person EricWF; 09.03.2017
comment
@EricWF: Я могу подтвердить, что флаг -isystem необходим при установке новой библиотеки libc ++, которая не перезаписывает существующую системную. У меня есть libc ++ - dev 3.7.0-1 в /usr/include и libc ++ - dev 3.9 в /usr/local/include. clang ++ пытается включить из /usr/local/include/c++/v1 и терпит неудачу с отсутствующим stddef.h. Глядя на проверку SVN libcxx, действительно нет stddef.h в каталоге include. - person Steve D; 19.04.2017
comment
@SteveD, сегодня я проверил исходник llvm плюс libc ++, и теперь он работает правильно. Больше не нужно передавать флаг -isystem. Попробуй обновить, поправлю свои выводы, можно ли их воспроизвести. - person Incomputable; 25.04.2017
comment
@Incomputable: у меня все работает, поэтому я не тороплюсь вносить какие-либо изменения :). Но если вы опубликуете свои шаги, я просмотрю их, чтобы проверить, работают ли они. Сделать это проще было бы огромным подспорьем! - person Steve D; 27.04.2017
comment
@SteveD, это то же самое, что и выше, только часть -isystem удалена. Я не устанавливал их, поэтому мне пришлось связать с общей библиотекой -Wl,-rpath,/absolute/path, как указано в этом ответе. Он работает "из коробки" и значительно упростил жизнь моим тестерам. Я думаю, что упрощение, вероятно, приведет к большой гибкости, так что это может быть не вариант. - person Incomputable; 27.04.2017