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

W>Можно будет сделать С++ — компилятор частью программы и компилировать С++ — код на лету?
Нет. То есть сделать это ты, конечно, можешь, но libgccjit тут никоим образом участвовать не будет и не поможет.

libgccjit — это библиотека доступа к backend'у компилятора. То есть на вход она получает нечто похожее на AST, а на выходе даёт машинный код под конкретную платформу.

Если же хочется компилировать C++, то тебе нужна frontend часть компилятора, которая собственно переведёт код из C++ в вид понятный backend части. Написание своего C++-frontend это, конечно, крайне сложная задача. Заточить уже существующий проще, но тоже потребует усилий. То есть ни того, ни другого варианта в готовом виде не существует и в непосредственном будущем существовать не будет.

Если уж стоит задача именно в динамической компиляции C++ кода, то разумнее всего взять просто полноценный компилятор (в standalone варианте, или завёрнутый в библиотеку) и запускать его. Это совершенно прямолинейный подход, но от этого получаемый результат не станет хуже.

Так что цель libgccjit не в том чтобы компилировать C++ код, а в том чтобы облегчить создание компиляторов, предоставив уже готовый backend. То есть, как и сказано в описании, если у тебя уже есть готовый frontend для своего языка, или виртуальная машина для какого-то своего байт-кода, и ты хочешь её ускорить, воспользовавшись наработками gcc, то эта библиотека — твой выбор.
Другой аналоги — это, например, llvm, который также умеет переводить описание программы из промежуточного кода в машинный. Ну и в некотором роде к аналогам можно добавить ещё и pypy, запущенный в режиме создания компилятора, а не в режиме одноимённого интерпретатора питона. Он тоже может создать по описанию виртуальной машины её jit версию, хотя там несколько другой подход.

W>А как его потом линковать с основной программой?
Динамически. Это просто вызов функции по указателю.
В результате компиляции будет просто получен контейнер с машинным кодом функций с одной или несколькими точками входа. Их вызов из основной программа как раз приведёт к выполнению той логики, которая была передана исходно в libgccjit. Работа идёт точно так же, как и при импорте функций из динамических библиотек с использованием, например, dlsym или GetProcAddress.
Ну и в режиме Ahead-of-Time можно сразу получить ту же .so, чтобы не компилировать программу каждый раз заново, а просто положить результат в файл и загружать функциями ОС (вроде уже упомянутых dlsym и GetProcAddress) без использования gcc.