Revision [16857]

This is an old revision of DevMakingReleases made by DkLwikki on 2013-06-22 12:51:31.


Notes on making FB releases

Packaging and Manifests
After FB, binutils and external libraries etc. have been compiled and/or copied into the FB tree, the contrib/release/pattern.bas program can be used to create the binary packages and corresponding manifests from the files in the FB tree.

$ fbc contrib/release/pattern.bas -g -exx
$ contrib/release/pattern {dos|linux|win32}

The manifests at contrib/release/manifest/*.lst will be regenerated. This can be used to check for extra/missing files in combination with Git's diff'ing capabilities. The include/exclude patterns in contrib/release/pattern.txt may need adjustment.

For the win32 build,, TDM-GCC or MinGW-w64 toolchains could be used. seems to be the most "standard", but apparently uses DW2 exception handling which results in huge .eh_frame sections in code generated by gcc, including libgcc.a etc. This is considered unacceptable bloat by some FB users.

TDM-GCC was used for some FB releases in the past because it provided GCC 4 while didn't yet. However has GCC 4 too nowadays.

MinGW-w64 is rather new but also used by many projects instead of Since they upstream all GCC patches it can be considered very "standard" aswell. When thinking about porting FB to 64bit Windows it'd make some sense to use MinGW-w64 toolchains for both the 32bit and 64bit versions.

SJLJ vs DW2 exception handling doesn't really matter for FB at the moment since it doesn't support exceptions, but it could still matter when using static C++ libraries linked into FB programs, such as ASpell, and it affects the binaries generated by gcc including gcc's own objects/libraries (such as libgcc.a or crtbegin.o/crtend.o).

Even though the core C ABI is surely compatible between the different GCC Win32 toolchains, there may be differences in libsupc++.a (which FB uses), or other files, due to the exception handling configuration, and besides that different GCC release versions themselves have ABI differences, e.g. 4.6 vs 4.7 changed structures to assume __attribute__((ms_struct)) by default, instead of __attribute__((gcc_struct)). These things could cause problems between different FB releases and different MinGW toolchains.


This is intended to be a build of FB for the toolchain, able to just be extracted into a MinGW tree like a MinGW package.


Building binaries that work on most of the available GNU/Linux distributions is hard because even though they are often similar in general, they differ in detail just as often. The most common problem is mismatching glibc versions, i.e. the fbc binary is run on a system with older glibc than the one it was built on, and an "glibc too old" error is encountered. The ncurses library is not always exactly the same either, as shown by the "`ospeed' has different size, consider re-linking" warnings when running fbc. That's why the Linux releases have usually been built in some GNU/Linux system old enough to let the fbc binary work on Debian 4 and 5, the current supported Ubuntu versions (especially LTSs), Fedora and OpenSUSE.

As of FB 0.24 it's possible to create static ELF binaries using musl libc instead of glibc, which should prevent the problems mentioned above. Other alternative libc's might work too, though I (dkl) tested only musl libc and dietlibc, and musl worked almost without problems, while compiling the rtlib with dietlibc required more adjustments. Besides getting the rtlib to build, the other big issue is getting the proper target libraries.

libc & co (including crt{1,i,n}.o) are easy to build from the musl sources, but properly compiling GCC to get libgcc, libsupc++ and crtbegin.o/crtend.o requires some experience. Luckily there is a script to create a musl libc GCC cross-compiling toolchains available at

The contrib/libs/linuxmusl/ script uses that to build a whole statically linked FB setup using musl libc, including statically linked binutils and gcc, and tons of external libraries. This resulted in the FB-linuxmusl package.


With DJGPP the choice is between the latest CVS version or the somewhat outdated DJGPP 2.04 beta release. Compiling DJGPP from CVS is not that much trouble though:
  • get the DJGPP 2.04 setup as a base
  • get & build DJGPPCVS with that ("make" in the src directory)
  • copy all packages (gcc/binutils/etc.) except the old djdev (libc, libm, headers, etc.) over into the DJGPP CVS tree
  • delete the DJGPP 2.04 setup
  • and use the CVS version in its place

This is intended to be a build of FB for DJGPP, able to just be extracted into a DJGPP tree like a DJGPP package.

FB manual/documentation

Back to FreeBASIC Developer Information

Back to Table of Contents
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki phatcode