Getting the FreeBASIC source code and compiling it
The source code of FreeBASIC is maintained on Sourceforge using the Git version control system, which allows different developers to work on the source code at the same time and later combine their work. It is possible for users to download this source code using anonymous read access and compile it using GNU development tools.
Compiling the development version is not recommended for most users. FreeBASIC is a self-hosting compiler, still in active development, so there will be times when the current development version cannot be compiled by the last official release. Note also that the procedures for building the compiler described here may change with future versions of FreeBASIC.
On Windows, MinGW/MSYS is used to compile FreeBASIC. Linux users will usually have the required development tools installed on their system already. The Cygwin build may be useful for Windows users wishing to access Linux libraries in windows. The DOS build is normally compiled on Windows using DJGPP. Advanced users may be able to cross-compile between other builds, but the correct development tools and libraries would be needed, and it has not been widely tested.
Previous guides (for compiling FB 0.23 and earlier)
Getting the current source code
Compiling for DOS using DJGPP on Win32
Compiling on x86 GNU/Linux
Compiling for x86 GNU/Linux on x86_64 GNU/Linux
Compiling on Win32 using TDM-GCC and MSYS
Compiling on Win32 using MinGW/MSYS, for installation into the MinGW tree
Getting source code updates and recompiling
Debugging FB
Makefile commands
Makefile configuration (variables to set on the make command line or inside config.mk)
Compiler source code configuration (FBCFLAGS)
rtlib and gfxlib2 source code configuration (CFLAGS)
Known problems and pitfalls
Previous guides (for compiling FB 0.23 [versions on or before September 20, 2011] and earlier)
Compiling from SVN for Cygwin
Compiling from SVN for Win32, using MSYS on Win32
Compiling from SVN for Linux
Compiling from SVN for DOS on Win32
Compiling from SVN for FreeBSD
Getting the current source code
The current source (FreeBASIC 0.24 [versions after September 20, 2011]) is available from these Git repositories:

- main repository at Sourceforge:

Git clone URL: `git://fbc.git.sourceforge.net/gitroot/fbc/fbc`
Web view: http://fbc.git.sourceforge.net/git/gitweb.cgi?p=fbc/fbc;a=summary

- Github mirror:

Git clone URL: `https://github.com/freebasic/fbc.git`
Web view: https://github.com/freebasic/fbc
If you need help with installing or using Git, search the web or check out the few Git tips here.
(Typical usage after installation: "git clone git://...")
Compiling for DOS using DJGPP on Win32

- The DOS version of FreeBASIC is typically compiled on a Windows system with DJGPP and a DOS version of FreeBASIC installed. Download the latest FreeBASIC-dos release from the FreeBASIC's download site. It should be extracted somewhere like `C:\FBDOS`. We'll use it to bootstrap the new FB compiler.
- The DJGPP packages can be found on the DJGPP homepage. FreeBASIC needs djdev204.zip from DJGPP 2.04 (DJGPP downloads directory: `beta/v2/`), but for the others it should be ok to use the ones from DJGPP 2.03 (DJGPP downloads directory: `current/v2gnu/`). Setup DJGPP by extracting everything into `C:\DJGPP` and adding an environment variable named "DJGPP", set to `C:\DJGPP\djgpp.env`.
  - `binutils` (`bnu*b.zip`, `bnu*a.zip`)
  - `bash` (`bsh*.zip`)
  - `djdev` (`djdev*.zip`) - pick up djdev204.zip or later from the `beta/` directory
  - `fileutils` (`fil*.zip`)
  - `gcc` (`gcc*b.zip`)
  - `gpp` (`gpp*b.zip`)
  - `gettext` (`gtxt*b.zip`) - libintl, for libbfd
  - `make` (`mak*b.zip`)
  - `shellutils` (`shl*b.zip`)
  - `textutils` (`txt*b.zip`)
  - `zlib` (`zlib*b.zip`) - zlib, for libbfd, from the `current/v2tk/` directory

It can be useful (especially when working in parallel with MinGW) to use a batch script to launch a terminal with the DJGPP tools in its PATH environment variable, instead of modifying the system's global PATH environment variable:

    set DJGPP=C:\DJGPP\djgpp.env
    set PATH=C:\DJGPP\bin;%PATH%
    set PATH=C:\FBDOS;%PATH%
    cd C:\
    cmd

- After having installed DJGPP and opened a command prompt with `C:\DJGPP\bin` in its path, running gcc should run the DJGPP gcc:

    > gcc --version
    gcc.exe (GCC) 4.7.1
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

- The traditional FB-dos setup is a standalone setup, so we will use ENABLE_STANDALONE for the new build.

Additionally, if and only if you are bootstrapping the compiler using an unmodified FB-dos release, use ENABLE_FBBFD=217, because FB-dos releases come with a libbfd.a 2.17. Otherwise, when using DJGPP's libbfd, leave out ENABLE_FBBFD. This happens for example when you're already using a self-built fbc that's using DJGPP's libbfd. If you want to avoid having to worry about which libbfd to link the new compiler against, then use DISABLE_OBJINFO.
Assuming the FreeBASIC sources are located at `C:\fbc-dos`, create a `C:\fbc-dos\config.mk` file containing something like the following:

    ENABLE_STANDALONE := YesPlease
    ENABLE_FBBFD := 217

    # (commented out)
    # DISABLE_OBJINFO := YesPlease

- Then, run "make" from a cmd.exe prompt and let it compile FB:

    > cd C:\fbc-dos
    > make

- Copy these files to `C:\fbc-dos\bin\dos`:
  - `C:\DJGPP\bin\{ar,as,ld}.exe`
- Copy these files to `C:\fbc-dos\lib\dos`:
  - `C:\DJGPP\lib\{crt0,gcrt0}.o`
  - `C:\DJGPP\lib\lib{emu,m}.a`
  - `C:\DJGPP\lib\gcc\djgpp\version\lib{gcc,supcxx}.a`, and rename `libsupcxx.a` to `libsupcx.a` (8.3 file name)
  - `C:\DJGPP\lib\lib{bfd,iberty,intl,z}.a` (DJGPP's libbfd, for recompiling FreeBASIC using this tree)
  - `C:\FBDOS\lib\dos\libc.a` - this should be the modified `libc.a` from the latest FreeBASIC release. To use the libc.a from DJGPP, the _main.o it contains needs to be replaced with the one compiled from `contrib/djgpp/libc/crt0/_main.c` from the fbc source code, to fix a bug in the original version from DJGPP.
  - and any additional libraries you want to use
- Rename `C:\fbc-dos\fbc-new.exe` to `C:\fbc-dos\fbc.exe`, if wanted
- The newly built FB setup can be tested right from the source tree, or you can copy it somewhere else. Make sure to copy all of the following files and directories:
  - `fbc.exe`
  - `bin/dos/`
  - `inc/`
  - `lib/dos/`

Compiling on x86 GNU/Linux

- First, we'll need a working FB setup to bootstrap the new FB compiler. Download the latest FreeBASIC-linux release from FreeBASIC's download site, then extract and install it:

    $ tar zxf FreeBASIC-X.XX.X-linux.tar.gz
    $ cd FreeBASIC-X.XX.X-linux
    $ sudo ./install.sh -i

- The following DEB packages plus dependencies are needed (with RPM names in parentheses):
  - `gcc`
  - `g++` (`gcc-c++`)
  - `binutils`
  - `binutils-dev` (`binutils-devel` or `binutils-static`) - libbfd for fbc's objinfo feature
  - `make`
  - `libncurses5-dev` (`ncurses-devel`)
  - `libx11-dev` (`libX11-devel`)
  - `libxext-dev` (`libXext-devel`)
  - `libxpm-dev` (`libXpm-devel`)
  - `libxrandr-dev` (`libXrandr-devel`)
  - `libxrender-dev` (`libXrender-devel`)
  - `libgpm-dev` (`gpm-devel`)
  - `libgl1-mesa-dev`, `libglu1-mesa-dev` (`Mesa-devel`) - OpenGL development files
  - `libffi-dev` (`ffi-devel`) - foreign function interface for `Threadcall`
- The traditional FB-linux setup is a normal FB setup that uses the system's tools and libraries.

Usually it's not necessary to put anything inside config.mk, unless you know you need it. For example, if your fbc is using its own libbfd.a 2.17 (for example because it is a FB-linux-standalone release) then you have to use ENABLE_FBBFD=217, but if you're using the usual FB-linux release, then your fbc should be using the system's libbfd, and nothing needs to be done. To be safe, you can use DISABLE_OBJINFO.

    # (commented out)
    # prefix := /usr/local
    # DISABLE_OBJINFO := YesPlease

- Assuming the FreeBASIC sources are located at `~/fbc`, run "make" there and let it compile FB:

    $ cd ~/fbc
    $ make

- Optionally, install the newly built into the path specified by the `prefix` variable (defaults to /usr/local):

    $ make install

Compiling for x86 GNU/Linux on x86_64 GNU/Linux

- Currently, FB only supports 32bit, and there is no 64bit port yet, but it is still possible to run and compile 32bit FB on a 64bit system. Just like with the 32bit GNU/Linux build, we'll need a working FB setup to bootstrap the new FB compiler. Download the latest FreeBASIC-linux release from FreeBASIC's download site, then extract and install it:

    $ tar zxf FreeBASIC-X.XX.X-linux.tar.gz
    $ cd FreeBASIC-X.XX.X-linux
    $ sudo ./install.sh -i

- The following DEB packages plus dependencies are needed:
  - `libc6-dev-i386`
  - `binutils`
  - `gcc-multilib`
  - `g++-multilib`
  - `lib32ncurses5-dev`
  - `make`
  - `libx11-dev` - for the X11 headers
  - `libxext-dev`
  - `libxpm-dev`
  - `libxrandr-dev`
  - `libxrender-dev`
  - `libgl1-mesa-dev` - for the OpenGL headers
  - `libglu1-mesa-dev`
  - `libgpm-dev` - for the GPM headers
  - `ia32-libs-dev` - for 32bit X11 and OpenGL development libraries on Debian
  - `lib32ffi-dev`
- Assuming the FreeBASIC sources are located at `~/fbc`, create a `~/fbc/config.mk` file with the following content:

    CC := gcc -m32
    TARGET_ARCH := x86
    DISABLE_OBJINFO := YesPlease

This tells the FB makefile to use `gcc -m32` instead of `gcc`, which causes all C code to be compiled for x86 rather than x86_64. Furthermore, explicitly setting the TARGET_ARCH to x86 is necessary to get the makefile to select the proper x86 rtlib/gfxlib2 modules, because otherwise the makefile would rely on the output of `uname -m`, which happens to be x86_64. But since we want to compile for 32bit, we need to override that. DISABLE_OBJINFO is used here to avoid libbfd problems - for example, a precompiled 32bit libbfd may not be available at all on 64bit GNU/Linux.

- Run "make" and let it compile FB:

    $ cd ~/fbc
    $ make

- Optionally, install the newly built into the path specified by the `prefix` variable (defaults to /usr/local):

    $ make install

Compiling on Win32 using TDM-GCC and MSYS

- We will need a working FB-win32 installation to bootstrap the new FB compiler. Download the latest FreeBASIC-win32 release from FreeBASIC's download site and extract/install it somewhere like `C:\FB-win32`.
- The Win32 version of FreeBASIC is typically compiled on Win32 using TDM-GCC (SJLJ -- setjump/longjump exception handling mode). Grab the TDM-GCC installer from http://tdm-gcc.tdragon.net/download and install the recommended TDM-GCC C and C++ packages into `C:\TDM-GCC`.
- The needed MSYS packages can be downloaded and extracted by using the latest version of the mingw-get program. It can be extracted into the same directory as TDM-GCC; then it would install the MSYS files into `C:\TDM-GCC\msys\1.0`, and as long as you do not use it to intall MinGW packages, there should be no conflict with the TDM-GCC files.
  - `msys-core`
  - `bash` (terminal/shell)
  - `msys-coreutils`
  - `msys-findutils` (xargs for running the test suite)
  - `msys-make`
- After installing MSYS, you can open the MSYS bash by running `C:\TDM-GCC\msys\1.0\msys.bat`. You have to make sure the FB makefile will find the fbc and gcc programs; in order to do this typically the `C:\TDM-GCC\bin` and `C:\FB-win32` directories are added to the PATH environment variable. In order to avoid modifying the system-wide PATH, you may use a .bat script like the following to open an MSYS bash with the needed PATH setting, everytime you need it:

    set PATH=%PATH%;C:\TDM-GCC\bin
    set PATH=%PATH%;C:\FB-win32
    C:\TDM-GCC\msys\1.0\msys.bat

- In order to compile FreeBASIC's gfxlib2, DirectX headers are needed in `C:\TDM-GCC\include`, specifically `ddraw.h` and `dinput.h`. You can get the headers from here: http://alleg.sourceforge.net/files/dx80_mgw.zip
- The traditional FB-win32 setup is a standalone setup, so we will use ENABLE_STANDALONE for the new build.

Additionally, if and only if you are bootstrapping the compiler using an unmodified FB-win32 release, use ENABLE_FBBFD=217, because FB-win32 releases come with a libbfd.a 2.17. Otherwise, when using TDM-GCC's libbfd, leave out ENABLE_FBBFD. This happens for example when you're already using a self-built fbc that's using TDM-GCC's libbfd. If you want to avoid having to worry about which libbfd to link the new compiler against, then use DISABLE_OBJINFO.
Assuming the FreeBASIC sources are located at `C:\fbc`, create a `C:\fbc\config.mk` file containing something like the following:

    # FB-win32 typically is built as standalone
    ENABLE_STANDALONE := YesPlease

    # For TDM-GCC which doesn't have libgcc_eh, unlike MinGW.org
    FBCFLAGS := -d ENABLE_TDMGCC

    # Only when using TDM-GCC's libbfd, if needed to satisfy its dependencies
    # FBLFLAGS := -l iconv -l advapi32

    # Only when using libbfd 2.17
    ENABLE_FBBFD := 217

    # To avoid worrying about libbfd, uncomment this:
    # DISABLE_OBJINFO := YesPlease

- Run "make" (from inside the MSYS bash) and let it compile FB:

    $ cd /c/fbc
    $ make

- Copy to `C:\fbc\bin\win32`:
  - `C:\TDM-GCC\bin\{ar,as,dlltool,ld}.exe`
  - `GoRC.exe` (from http://www.godevtool.com/ or the previous FreeBASIC release)
- Copy to `C:\fbc\lib\win32`:
  - `C:\TDM-GCC\lib\{crt2,dllcrt2,gcrt2}.o`
  - `C:\TDM-GCC\lib\lib{gmon,mingw32,mingwex,moldname}.a`
  - `C:\TDM-GCC\lib\gcc\mingw32\version\{crtbegin,crtend}.o`
  - `C:\TDM-GCC\lib\gcc\mingw32\version\lib{gcc,supc++}.a`
  - `C:\TDM-GCC\lib\lib{advapi32,gdi32,kernel32,msvcrt,user32,winmm,winspool}.a` (rename to `lib*.dll.a`)
  - `C:\TDM-GCC\lib\lib{bfd,iberty,intl,iconv}.a` (For recompiling FreeBASIC using this tree)
  - and any additional libraries you want to use
- Rename `C:\fbc\fbc-new.exe` to `C:\fbc\fbc.exe`, if wanted
- The newly built FB setup can be tested right from the source tree, or you can copy it somewhere else. Make sure to copy all of the following files and directories:
  - `fbc.exe`
  - `bin/win32/`
  - `inc/`
  - `lib/win32/`

Compiling on Win32 using MinGW/MSYS, for installation into the MinGW tree

- We will need a working FB-win32 installation to bootstrap the new FB compiler. Download the latest FreeBASIC-win32 release from FreeBASIC's download site and extract/install it somewhere like `C:\FB-win32`.
- To install MinGW/MSYS, download the latest version of the mingw-get program and extract it into `C:\MinGW`. After that open a command prompt (cmd.exe) and run:

    > C:\MinGW\bin\mingw-get.exe update
    > C:\MinGW\bin\mingw-get.exe install

The following packages need to be installed via `mingw-get install` (or by downloading & extracting them manually):

- `gcc-core`
- `gcc-g++` (only needed to get libsupc++.a)
- `binutils` (binutils, and binutils-dev for libbfd)
- `mingwrt`
- `w32api`
- `gettext-dev` (libintl for libbfd)
- `msys-core`
- `bash` (terminal/shell)
- `msys-coreutils`
- `msys-findutils` (xargs for running the test suite)
- `msys-make`

- After installing MSYS, you can open the MSYS bash by running `C:\MinGW\msys\1.0\msys.bat`. You have to make sure the FB makefile will find the fbc and gcc programs; in order to do this, typically the `C:\MinGW\bin` and `C:\FB-win32` directories are added to the PATH environment variable. In order to avoid modifying the system-wide PATH, you may use a .bat script like the following to open an MSYS bash with the needed PATH setting, everytime you need it:

    set PATH=%PATH%;C:\MinGW\bin
    set PATH=C:\FB-win32;%PATH%
    C:\MinGW\msys\1.0\msys.bat

It is also possible to use MinGW/MSYS programs from the cmd.exe command prompt, if you prefer. For that it may be worth it to add `C:\MinGW\bin`, `C:\MinGW\msys\1.0\bin` and `C:\FB-win32` to the system's global PATH environment variable.

- In order to compile FreeBASIC's gfxlib2, DirectX headers are needed in `C:\MinGW\include`, specifically `ddraw.h` and `dinput.h`. You can get the headers from here: http://alleg.sourceforge.net/files/dx80_mgw.zip
- This fbc build for MinGW will be a normal build, with the same directory structure as on Linux.

If and only if you are bootstrapping the compiler using an unmodified FB-win32 release, use ENABLE_FBBFD=217, because FB-win32 releases come with a libbfd.a 2.17. Otherwise, when using MinGW's libbfd, leave out ENABLE_FBBFD. This happens for example when you're already using a self-built fbc that's using MinGW's libbfd. If you want to avoid having to worry about which libbfd to link the new compiler against, then use DISABLE_OBJINFO.
Assuming the FreeBASIC sources are located at `C:\fbc`, create a `C:\fbc\config.mk` file containing something like the following:

    prefix := C:/MinGW

    # Only when using libbfd 2.17
    ENABLE_FBBFD := 217

    # To avoid worrying about libbfd, uncomment this:
    # DISABLE_OBJINFO := YesPlease

- Run "make" (from inside the MSYS bash) and let it compile FB:

    $ cd /c/fbc
    $ make

- Optionally, install the newly built FB into the path specified by the `prefix` variable:

    $ make install

Getting source code updates and recompiling
To download updates made available in the fbc Git repository, you can do a pull, either using your preferred graphical Git tool, or in a terminal:

    git pull

To take a look at incoming changes before applying them, do this:

    # Update remote branches
    git fetch

    # Take a look
    gitk --all

    # Everything looks ok? Then merge the remote branch into the current branch to apply the update.
    git merge origin/master

Rebuilding is, most of the time, as easy as:

    make

If compilation options (like ENABLE_STANDALONE) were used for the previous build, it's necessary to specify them again this time, unless they are (still) set in `config.mk`.
As a special exception, for the DOS build it is necessary to run `make clean` before `make` to properly rebuild FB after source modules have been renamed or deleted. The reason for this is that under DOS/DJGPP the makefile uses *.o wildcards to link fbc and archive libfb.a etc., instead of passing the explicit .o file names, because it has to obey the command line length limitation. If `make clean` is not run, it may use old left-over object files from a previous build.
Debugging FB
For debugging and development it's a good idea to build the compiler with -g and -exx to enable assertions and NULL pointer/array boundary checks. For the rtlib/gfxlib2 code, -DDEBUG enables the assertions. Just update config.mk and (re)build. Example config.mk settings:

    FBFLAGS := -g -exx
    CFLAGS := -g -O0 -DDEBUG

Running fbc inside gdb would typically look something like:

    gdb --args fbc test.bas

Also note that fbc can be tested right from inside the build tree, without being "installed" somewhere else, which also is a great debugging and development help.
Makefile commands

- none or `all`

The default - builds everything that needs to be built

- `compiler`, `rtlib`, `gfxlib2`

Used to build a specific component only. For example, this can be used to build an `rtlib` for a specific target, in order to be able to cross-compile FB programs (such as the `compiler`) for that target.

- `clean[-component]`

Used to remove built files. `make clean` removes all built files, while for example `make clean-compiler` removes only the files built for the compiler, allowing the compiler to be recompiled more quickly, without the need to rebuild the whole rtlib/gfxlib2 code.

- `install[-component]`, `uninstall[-component]`

Used to copy the built files into the directory specified by the `prefix` variable, or remove them from there. This is most useful to install the normal build into /usr/local on Linux/BSD systems. For the standalone build, `make install` will also work and copy over or remove the files. However, the standalone build uses an incompatible directory layout and should not be installed into /usr/local or similar directories because of this.
Note that it is fine to run the newly built FB setup right from the directory where it was compiled; `make install` is not necessary to make it work (unless the prefix path was hard-coded into the compiler via ENABLE_PREFIX).
Additionally there are `install-includes` and `uninstall-includes` commands, which copy/remove just the FB includes (header files). Note that there is no `make includes` or similar command, as the includes do not need to be built.
Makefile configuration (variables to set on the make command line or inside config.mk)

- `FBFLAGS`, `FBCFLAGS`, `FBLFLAGS`

Extra fbc flags to be used when compiling and/or linking the compiler

- `CFLAGS`

Extra gcc flags to be used when compiling rtlib and gfxlib2
These do not affect the compilation of the compiler's bfd-wrapper.c module.

- `prefix`

Changes the /usr/local prefix to something else. Note: MSYS maps `/usr/local` to `C:\msys\1.0\local`.
This is only used...

- by the makefile's `install` and `uninstall` commands,
- in the compiler (hard-coded) if ENABLE_PREFIX was used

Note that in combination with bash on Win32 (e.g. from DJGPP or MSYS) it's necessary to use forward slashes instead of backslashes in directory paths, for example: `prefix=C:/MinGW`

- `TARGET`

This variable can be set to a system triplet in order to cross-compile using that GCC cross-compiler toolchain. The makefile will use `fbc -target $(TARGET)` instead of `fbc`, and `$(TARGET)-gcc` instead of `gcc`.
For example, on a Debian GNU/Linux system with the i686-w64-mingw32 GCC cross-compiler installed, you can build the win32 rtlib like this:

    # Build the win32 rtlib/gfxlib2
    make rtlib gfxlib2 TARGET=i686-w64-mingw32

    # Install it into /usr/local/lib/i686-w64-mingw32-freebasic
    make install-rtlib install-gfxlib2 TARGET=i686-w64-mingw32

It will supplement the existing fbc installation in /usr/local, like a plugin, and from now on you can cross-compile FB programs for win32 by doing:

    fbc -target i686-w64-mingw32 ...

- `FBC`, `CC`, `AR`

These variables specify the fbc, gcc and ar programs used during the build. You can specify them to override the defaults, for example:

- `make FBC=~/FreeBASIC-0.23.0-linux/fbc`
- `make CC="gcc -m32"`

`FBC` affects the `compiler` source code only, while `CC` and `AR` are used for `rtlib` and `gfxlib2`. `CC` is additionally used for the compilation of the compiler's bfd-wrapper.c module.

- `V`

`V` for verbose. By default, the makefile does not display the full command lines used during compilation, but just prints out the latest tool and file name combination to give a better visual indication of the build progress. It also makes warnings and errors stand out more in the console window. If the variable `V` is set, the echoing tricks are disabled and full command lines will be shown, as GNU make normally does.

- `ENABLE_STANDALONE=1`

Build a standalone FB setup instead of the normal Unix-style setup, see also: the standalone vs. normal comparison. This causes the makefile to use the standalone directory layout and to use `-d ENABLE_STANDALONE` when building the compiler.

- `DISABLE_OBJINFO=1`

This causes the makefile to use `-d DISABLE_OBJINFO` when building the compiler, and additionally not to build the compiler's bfd-wrapper.c module.

- `ENABLE_FBBFD=217`

This causes the makefile to use `-d ENABLE_FBBFD=217` when building the compiler, and additionally not to build the compiler's bfd-wrapper.c module.

- `ENABLE_PREFIX=1`

This causes the makefile to use `-d ENABLE_PREFIX=$(prefix)` when building the compiler.

- `ENABLE_SUFFIX=foo`

This causes the makefile to use `-d ENABLE_SUFFIX=$(ENABLE_SUFFIX)` when building the compiler, and to append the given suffix string to the fbc executable's and lib/ directories' names.
For example, using `ENABLE_PREFIX=-0.24` will give you fbc-0.24.exe and a lib/freebasic-0.24/ directory, instead of fbc.exe and lib/freebasic/. This allows installing multiple versions of compiler and runtime in parallel. Note: The include/ directory name is not affected, and the FB headers are always shared by all installed FB versions (FB's headers and their directory layouts are designed to be able to do that). This is only supported for the normal (non-standalone) build.
Compiler source code configuration (FBCFLAGS)

- `-d ENABLE_STANDALONE`

This makes the compiler behave as a standalone tool that cannot rely on the system to have certain programs or libraries. See the normal vs. standalone comparison for more information.

- `-d DISABLE_OBJINFO`

This disables the compiler's objinfo feature, and thus removes the need for libbfd. This is especially useful to avoid problems with libbfd; see the libbfd pitfall section under Known Problems for more information.

- `-d ENABLE_FBBFD=217`

This causes the compiler to use FB headers for libbfd, instead of using the bfd-wrapper.c module. This is what's done at least for FB releases. Please see the libbfd pitfall section under Known Problems for more information.

- `-d ENABLE_TDMGCC`

This makes the compiler work with TDM-GCC libraries instead of MinGW.org libraries. Currently the only difference is that under MinGW.org, the compiler has to link in libgcc_eh to satisfy dependencies, while this is not needed under TDM-GCC, which does not even have this library. The difference is caused by the exception handling mechanisms the toolchains are configured to use: TDM-GCC with SJLJ, MinGW.org with DW2.

- `-d ENABLE_SUFFIX=foo`

This makes the compiler append the given suffix to the lib/freebasic/ directory name when searching for its own lib/freebasic/ directory. For example, `-d ENABLE_SUFFIX=-0.24` causes it to look for lib/freebasic-0.24/ instead of lib/freebasic/. This is only supported for the normal (non-standalone) build.

- `-d ENABLE_PREFIX=/some/path`

This causes the given prefix path to be hard-coded into the compiler. It will no longer use exepath() and be relocatable. This may only be useful if its known that the compiler does not need to be relocatable, or if exepath() does not work.
rtlib and gfxlib2 source code configuration (CFLAGS)

- `-DDISABLE_X11`

With this, the Unix rtlib/gfxlib2 will not use X11 headers, disabling gfxlib2's X11 graphics driver and some of the rtlib's Linux console functionality (affects multikey() and console mouse handling)

- `-DDISABLE_GPM`

With this, the Linux rtlib will not use General Purpose Mouse headers (gpm.h), disabling the Linux GetMouse functionality.

- `-DDISABLE_FFI`

With this, the rtlib will not use libffi headers (ffi.h), disabling the ThreadCall functionality.

- `-DDISABLE_OPENGL`

With this, the gfxlib2 will not use OpenGL headers, disabling the OpenGL graphics drivers.
Known problems and pitfalls
libbfd pitfall
By default the compiler uses bfd-wrapper.c to access libbfd through the bfd.h found by gcc. You have to make sure to link against the proper corresponding libbfd.a/.so, not another one! (due to the unstable libbfd API)
If you know the specific libbfd version the compiler will be linked against, you can use ENABLE_FBBFD=version. Then the makefile will build the compiler with `-d ENABLE_FBBFD=version`, causing it to use FB libbfd headers for that version, instead of compiling in the version agnostic bfd-wrapper.c.
Careful: the official FB standalone (linux/win32/dos) setups contain a libbfd.a 2.17, which will typically not match the bfd.h/libbfd.a/.so on the system. When boostrapping/building the compiler with such an FB setup you should use ENABLE_FBBFD=217. Here, using the default bfd-wrapper.c (compiling against bfd.h, but linking with an incompatible libbfd.a) is wrong. As an alternative it's possible to overwrite FB's libbfd.a with the one from the system, to make the libbfd.a against which the compiler will be linked match bfd.h.
Normally though, when building the compiler with an FB setup that does not come with its own libbfd.a, it's preferable to use the bfd-wrapper.c to use the system's libbfd. This is the case when bootstrapping/building the compiler using the normal non-standalone FB setup.
The way to avoid all the libbfd trouble is to use DISABLE_OBJINFO.
Newly built fbc crashes inside a bfd_*() function from libbfd
This is typically caused by libbfd header/library version mismatches, see above.
Win32 rtlib compilation error: _controlfp, _PC_64 undeclared

    CC src/rtlib/obj/hinit.o
    src/rtlib/win32/hinit.c: In function 'fb_hInit':
    src/rtlib/win32/hinit.c:21:5: warning: implicit declaration of function '_controlfp' [-Wimplicit-function-declaration]
    src/rtlib/win32/hinit.c:21:17: error: '_PC_64' undeclared (first use in this function)

Both the MinGW runtime and MinGW GCC have a `float.h` header, and in some setups the GCC one is found before the MinGW one, causing the above errors. This issue shows up with some MinGW setups, for example gcc-core-4.6.1 + mingwrt-3.20, while for example gcc-core-4.5.2 + mingwrt-3.18 (a previous installation made with mingw-get) works fine. This problem also shows up with mingw32 cross compiler on Debian (gcc 4.4.4, mingwrt 3.13).
Easiest temporary fix: Append `#include_next <float.h>` to `C:\MinGW\lib\gcc\mingw32\version\include\float.h`
See also:

- The comments at the top of `C:\MinGW\include\float.h`
- MinGW GCC 4.6.1 bug report
- MinGW patch tracker, 2010
- http://lists.nongnu.org/archive/html/mingw-cross-env-list/2010-06/msg00038.html
- http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
- https://sourceforge.net/mailarchive/message.php?msg_id=28122574

Warning: .drectve ... unrecognized when linking fbc

    CC src/compiler/obj/bfd-wrapper.o
    LINK bin/fbc-new.exe
    Warning: .drectve `-aligncomm:"_FB_bfd_format",2 '
    Warning: .drectve `-aligncomm:"_FB_bfd_architecture",2' unrecognized

This happens when fbc's C libbfd wrapper module (`bfd-wrapper.c`) is used and compiled with a modern GCC (such as GCC 4.5.x, 2010), and the new fbc.exe is being linked by the old ld 2.15 (2005) from the current FreeBASIC-win32 releases. The old ld complains about not knowing some sections that were added to later binutils.
This is not known to cause any issue besides the warning, and can be solved by replacing the old ld.exe in the FreeBASIC-win32 installation by a newer one from MinGW.
MinGW binutils ld versions 2.18 to 2.21
fbc triggers a bug (ld/12614) in the mentioned linker versions causing it to produce broken binaries. It's fixed in binutils 2.21.1 and up.
-lXpm not found on Debian x86_64
The ia32-libs-dev package (for example on Debian 6) for some reason does not contain a /usr/lib32/libXpm.so symlink, even though it does contain those for the other X11 development libraries. This apparently can be fixed by creating the symlink manually:

    ln -s /usr/lib32/libXpm.so.4 /usr/lib32/libXpm.so