За неделю мне попались две программы, в которых используется C++17
include <filesystem>, где прежде была абстракция из Boost-а. И у меня
оно не компилировалось, ибо не находит этот <filesystem>. Действительно,
при сборке используется штатный /usr/include, который у меня в системе
старый и в нём никаких <filesystem> просто ещё не было реализовано и всё
собрано на Clang 6.x ещё древнем.
Но я использую LLVM/Clang 14.x установленном через GNU Stow в ~/local,
где есть ~/local/include/c++/v1/filesystem. Пробую добавить этот путь
через -I -- ругается на то, что не может найти __config_state. Он есть в
include/x86_64-unknown-freebsd12.0/c++/v1/. Если его добавить в -I, то
дальше лавина ошибок из-за каких-то проблем с define-ами.
Под GNU GCC в GNU/Linux этот <filesystem> работает. Под виртуальной
машиной запускаю FreeBSD 13.1 с Clang-ом 13.x -- тоже всё работает, хотя
filesystem тоже под c++/v1.
Verbose показывает что при компиляции c++ (14.x) не пытается смотреть в
c++/v1 поддиректорию свою, а смотрит только в /usr/include, где старьё
сплошное, и в -I директории. Смотрю на вывод verbose под FreeBSD 13.1.
И разница только у указании "isystem" директории. Пробую повторить
полную команду "clang ... -triple x86_64-... -x c++" у себя локально, но
указывая isystem директорию ~/local/include/c++/v1. Снова падает на
невозможности найти __config_state. Скопировал его, ибо там ничего кроме
простых define-ов нет, и всё компилируется. Выходит что это не тоже
самое что просто добавление -I директории. Благо, в clang в 2019-ом году
добавили опцию -stdlib++-isystem, которая может переопределить эту
isystem.
Компилируется теперь с <filesystem> успешно, но не запускается. Уже
потому что libstdc++ не содержит всего нужного. Пришлось добавить в
LD_LIBRARY_PATH и ~/local/lib/x86_64-unknown-freebsd12.0.
Но перед этим кучу времени потратил на перекомпилирования LLVM-а, думая
что он как-то вообще не так собирает или не собирает вовсе этот
filesystem.