Выбор GCC инструментария
 

FB основан на GCC инструментарии и соответствующих библиотеках. Тем не менее, нет единого GCC инструментария для каждой платформы, чаще несколько слегка различных. FB может работать со всеми из них, но все же могут быть различия в зависимостях в наборе инструментов, выбранного для построения и использования FB. Здесь мы задокументировали некоторые вопросы, которые касаются построения\использования FB релизов.

Windows (MinGW)

MinGW инструментарий:

  • MinGW.org - также обеспечивает MSYS, помимо MinGW GCC инструментария. Отсутствует поддержка Win64 (пока).
  • MinGW-w64 - 32бит и 64бит. Различные runtime библиотеки в отличии от MinGW.org.
  • TDM-GCC - 32бит основе MinGW.org, 64бит основе MinGW-w64, с изменениями.
  • MinGW кросс-компиляторы различных дистрибутивов GNU / Linux - например MinGW-w64 на Debian / Ubuntu и Fedora (i686-w64-mingw32, x86_64-w64-mingw32)

Примечания:

  • Механизм обработки исключений GCC: SJLJ setjump/longjump (медленно но безопасно), DWARF-2 (быстро, но не всегда работает). Инструментарий MinGW.org использует DWARF2, а для MinGW-w64, доступны оба типа.
FB не поддерживает исключения так или иначе, поэтому в теории механизм, использования базового набора инструментов GCC для обработки исключений не имеет значения.

На практике однако, DWARF-2 GCC производит статические данные для раскручивания стека, которые помещаются в секцию .eh_frame. Проблема этой секции .eh_frame в том , что данные также создаются для кода C (не только C++) и для всех runtime библиотек FB/GCC/MinGW, и это заметно увеличивает размер .exe. Избежать этого можно несколькими способами:

      • Использовать gcc флаги для отключения создания данных .eh_frame. FB использует это в своих makefile и для -gen gcc, однако очевидно, что это не влияет на готовые библиотеки MinGW/GCC (если перестраивается весь инструментарий).
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables
      • Отказаться от секции .eh_frame при линковке (при помощи обычного ldscript)
      • Использовать SJLJ инструментарий (т.е. MinGW-w64, построенный для SJLJ, вместо MinGW.org)
Однако метод обработки исключений может быть важной деталью (даже если вы не заботитесь о размере .exe) если вы хотите использовать C++ библиотеки из FB, в случае, если C++ библиотека использует исключения.

  • GCC, модель потоков: потоки Win32 (нативные), POSIX потоки (на основе библиотеки winpthreads). MinGW.org набор инструментов использует потоки Win32, в то время как для MinGW-w64 доступны оба типа.
GCC нуждается в потоках POSIX для реализации некоторых новых возможностей C++, что невозможно с нативными потоковыми функциями Win32. Таким образом MinGW-w64 использует библиотеку winpthreads, которая обеспечивает функции POSIX-потоков для Windows. Однако winpthreads не является частью основной среды выполнения MinGW-w64, и она имеет другую лицензию, которая должна приниматься во внимание.

Так как FB не заботится об этих функциях C++, мы можем просто использовать MinGW инструментарий с потоками Win32 и избежать winpthreads.
  • Подстановка (Раскрытие шаблонов в командной строке  и т.д.) ; поведение отличается между MinGW.org и MinGW-w64, потому что они имеют различные runtime библиотеки\код запуска.
    • Подстановка включена по умолчанию в среде выполнения MinGW.org, но в среде выполнения MinGW-w64 подстановка отключена по умолчанию и имеет опцию конфигурации --enable-wildcard. Таким образом включена или выключена подстановка по умолчанию, зависит от того, как MinGW-w64 был построен.
    • Способ отключить подстановку отличается:
      • MinGW.org:
Extern _CRT_glob Alias "_CRT_glob" As Long
Dim Shared _CRT_glob As Long = 0

      • MinGW-w64:
Extern _dowildcard Alias "_dowildcard" As Long
Dim Shared _dowildcard As Long = 0

  • MinGW-w64 включает DirectX заголовки, необходимые для компиляции графической библиотеки FB. MinGW.org не содержит их; они должны быть добавлены вручную.
  • MinGW.org обеспечивает общий инсталлятор для их MinGW набора инструментов и среды оболочки MSYS. Это делает установку проще, чем с другими инструментами, которым необходимо MSYS.

DOS (DJGPP)

FB требует DJGPP 2.04 beta runtime ( DJGPP 2.03 не работает?). В любом случае, эта версия DJGPP очень старая. С другой стороны не было отмечено каких-либо более поздних релизов DJGPP, и обновления можно найти только в DJGPP в CVS. Рекомендуется использовать только DJGPP CVS, если действительно необходимо.

Linux

GNU/Linux дистрибутивы обычно предоставляют нативные gcc + glibc компилированные инструменты из коробки, и FB предназначен для работы с ними.

Исполняемые (например тот же FBC), произведенные на одном GNU / Linux дистрибутиве не обязательно подходят для других дистрибутивов GNU / Linux, в силу различий в системных библиотеках и / или версиях, таких как различия версий Glibc, или различия Ncurses / libtinfo. Наиболее распространенная проблема с FBC является несоответствия GLibC версии, т.е. FBC работает на системе с более старой Glibc, чем та с которой был построен, в итоге получаются некоторые формы ошибок "glibc too old". Библиотека ncurses тоже не всегда точно та же, как требуется и это приводит к предупреждениям fbc "`ospeed' has different size, consider re-linking" . Кроме того некоторые дистрибутивы отделили от своего дистрибутива libncurses и libtinfo или только libncurses, и это также приводит к ошибках вроде: libtinfo shared library not being found.

В теории можно использовать статическое связывание, чтобы избежать проблем с разделяемыми библиотеками:

  • Опция командной строки fbc -static указывает линкеру предпочитать статические библиотеки вместо общих. Это может (в теории) также использоваться при построении самого fbc. Он будет опираться в дистрибутиве Linux на статические версии системных библиотек. Статическое линкование на GNU/Linux обычно не рекомендуется, в частности с glibc (некоторые из его компонентов не предназначены для статических ссылок) и в целом разделяемые библиотеки предпочтительны в плане избыточности лишнего двоичного кода.
  • FB (в теории) также может быть использован с различными libc (вместо glibc), который явно поддерживает статическое связывание, например musl-libc.
В этом контексте, как правило, используется пользовательский набор инструментов GCC, что также требует, чтобы FB будет построен специально для этого набора инструментов. Такой подход в целом работает довольно хорошо, но это может вызвать много работы.

Кроме того, другие Libc не могут иметь ABI совместимость с glibc, в итоге это может вызвать проблемы для программ FB, если они написаны для Glibc. Это наиболее заметно при использовании FB Linux CRT заголовков для glibc. Примером разницы ABI между MUSL-LIBC (0,9) и Glibc является размер структуры jmp_buf (используется с функциями setjmp()/longjmp()). Определенные заголовки FB CRT glibc jmp_buf, несовместимы в musl-libc, который используется меньшую структуру jmp_buf.

Еще одной головной болью при использовании различных libc, взамен Glibs из Linux дистрибутив по умолчанию является, что вам также нужно построить много библиотек, таких как ncurses, X11 и Mesa/OpenGL для того, чтобы удовлетворить FB зависимости без упоминания других сторонних библиотек. Существующие библиотеки, скомпилированные для glibc вероятно не могут быть использованы (по крайней мере не безопасно) из-за несовместимостей ABI.

См. также