GCC toolchain choice

FB is based on GCC toolchains and corresponding libraries. However, there is not a single GCC toolchain per platform, but often multiple slightly different ones. FB can generally work with all of them, but still there can be differences depending on the toolchain chosen to build and use FB. Here we document some of the issues to consider when building FB and/or making FB releases.

Windows (MinGW)

MinGW toolchains:


FB does not support exceptions anyways, so in theory the exception handling mechanism used by the underlying GCC toolchain does not matter.

In practice though, DWARF-2 GCC generates static data for stack unwinding which is put into .eh_frame sections. The problem is that .eh_frame data is generated also for C code (not just C++ code) like all the FB/GCC/MinGW runtime libraries, and it increases .exe size noticably. This can be avoided in multiple ways:

  • Use gcc flags to disable the generation of the .eh_frame data. FB is using this in its makefile and for -gen gcc, however obviously it does not affect the prebuilt MinGW/GCC libraries (unless the entire toolchain is rebuilt).
  • -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables

  • Discard/strip the .eh_frame section when linking (by using a custom ldscript)
  • Use an SJLJ toolchain (i.e. MinGW-w64 built for SJLJ, instead of MinGW.org)

Furthermore, the exception handling method may be an important detail afterall (even if you do not care about .exe size) if you want to use C++ libraries from FB, in case the C++ library uses exceptions.

GCC needs POSIX threads to implement certain new C++ features, which is not possible with native Win32 threading functions. Thus, MinGW-w64 uses the winpthreads library which provides POSIX threading functions for Windows. However, winpthreads is not part of the main MinGW-w64 runtime, and it has a different license, which may have to be considered.

Since FB does not care about these C++ features, we can just use MinGW toolchains with Win32 threads, and avoid winpthreads.

  • Globbing is enabled by default in the MinGW.org runtime, but the MinGW-w64 runtime turns globbing off by default and has a --enable-wildcard configure option. Thus, whether globbing is on or off by default, depends on how MinGW-w64 was built.

  • The way to disable globbing is different:
    • 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


FB needs the DJGPP 2.04 beta runtime (does DJGPP 2.03 not work?). Either way, this version of DJGPP is extremely old. On the other hand, there have not been any more recent DJGPP releases, and updates can only be found in DJGPP's CVS. The recommendation is to only use DJGPP CVS if really needed though.


GNU/Linux distros usually provide native gcc + glibc toolchains out-of-the-box, and FB is intended to work with them out-of-the-box.

Executables (such as fbc itself) produced on one GNU/Linux distro are not necessarily portable to other GNU/Linux distros, due to differences in system libraries and/or versions, such as glibc version differences, or ncurses/libtinfo differences. The most common problem with fbc 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 some form of "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. Also, some distros have separated libncurses and libtinfo, some just have libncurses, which can cause errors due to the libtinfo shared library not being found.

In theory, it is possible to use static linking to avoid the problems with shared libraries:

In this context, you will typically use a custom gcc toolchain, which also requires FB to be built specifically for that toolchain. This approach in general works quite well, but it can be a lot of work.

Besides that, other libc's may not be ABI-compatible with glibc, which can cause problems for FB programs if they are written for glibc. Most noticably, the FB Linux CRT headers are based on glibc. An example of an ABI difference between musl-libc (0.9) and glibc was the jmp_buf structure size (used with the setjmp()/longjmp() functions). As the FB CRT headers defined the glibc jmp_buf, they were incompatible to musl-libc which used a smaller jmp_buf structure.

Another headache when using a different libc than the Linux distro default is that you also need to build a lot of libraries such as ncurses, X11 and Mesa/OpenGL in order to satisfy FB's dependencies, not to mention any other third-party libraries you want to use in your program. Existing libraries precompiled for glibc can probably not be used (at least not safely) due to the two libc's being ABI-incompatible.

See also:
Back to FreeBASIC Developer Information

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

sf.net phatcode