После того, как FB, binutils и внешние библиотеки были скомпилированы и/или скопированы в дерево FB, может использоваться программа contrib/release/pattern.bas для создания двоичных пакетов и соответствующих деклараций из файлов в дереве FB.

Манифесты в contrib/release/manifest/*.lst будут регенерированы. Это может использоваться для проверки на дополнительные/недостающие файлы в сочетании с возможностями Git's diff'ing. Включение/Исключение патернов в contrib/release/pattern.txt, возможно понадобится подкорректировать.

Для сборки win32 могут использоваться MinGW.org, TDM-GCC или MinGW-w64 инструменты.

MinGW.org, кажется, является самым "стандартным", но очевидно использует обработку исключений DW2, которая приводит к огромным разделам .eh_frame в коде, сгенерированном gcc, включая libgcc.a и т.д. Некоторые пользователи FB это считают недопустимым чрезмерным увеличением размера.

TDM-GCC использовался для некоторых выпусков FB в прошлом с помощью GCC 4, в то время как MinGW.org еще не использовался. Однако, в настоящее время у MinGW.org есть версия GCC 4.

MinGW-w64 довольно новый, но он уже успел обновиться различными патчами , так что его так же можно считать "стандартным". При размышлении о портировании FB для Windows 64 бита имело бы некоторый смысл использовать MinGW-w64 инструменты для 32\64 битных версий.

SJLJ по сравнению с обработкой исключений DW2 действительно не имеет значения для FB в данный момент, так как это не поддерживает исключения, но это может иметь значение при использовании статических библиотек C++, соединенных с программами FB, такие как ASpell, и это влияет на двоичные файлы, сгенерированные gcc включая собственные объекты/библиотеки gcc (такие как libgcc.a или crtbegin.o/crtend.o).

Даже при том, что ядро C ABI совместимо между различным Win32 GCC инструментами, могут быть различия в libsupc ++. (которую использует FB), или другими файлами, из-за конфигурации обработки исключений, и помимо этого различные выпуски GCC имеют различия в ABI, например, 4.6 по сравнению с 4.7 измененными структурами, принимают __attribute__((ms_struct)) по умолчанию, вместо __attribute__((gcc_struct)). Эти вещи могли вызвать проблемы между различными выпусками FB и различным MinGW инструментами.

Предназначено для того, чтобы быть сборкой FB для MinGW.org инструментария, который может быть просто быть извлечен в дерево MinGW как пакет MinGW.

С FB версии 0.24 есть возможность создать статические двоичные файлы ELF, используя musl libc вместо glibc, который должен предотвратить упомянутые выше проблемы. Другой альтернативный libc's мог бы работать также, хотя я (dkl) протестировал только musl libc и dietlibc, и musl работал почти без проблем, в то время как компиляция rtlib с dietlibc потребовала большего количества корректировок. Кроме того, получение rtlib построения, выливается в другую большую проблему предоставления необходимых целевых библиотек.

libc & Ко (включая crt{1,i,n}.o) легко создать из musl источников, но правильная компиляция GCC, с получением libgcc, libsupc ++ и crtbegin.o/crtend.o требует некоторого опыта. К счастью есть сценарий для создания musl libc GCC кросс-компилирующих инструментов доступный из https://github.com/GregorR/musl-cross.

Сценарий contrib/libs/linuxmusl/build.sh используется для того, чтобы создать целую статически соединенную установку FB, используя musl libc, включая статически слинкованный binutils и gcc и тонны внешних библиотек. Это привело к пакету FB-linuxmusl.

С DJGPP выберите между последней версией CVS или несколько устаревшей бета-версией DJGPP 2.04. Компиляция DJGPP из CVS не является большой проблемой:

Это предназначено, чтобы быть сборкой FB для DJGPP, который в состоянии просто быть извлеченным в дерево DJGPP как пакет DJGPP.