Known problems when compiling FB
Win32 rtlib compilation error: wchar.h: unknown type name 'dev_t'
http://sourceforge.net/p/mingw/bugs/2039/
The wchar.h header file from MinGW.org contains a struct _stat64 declaration that does not compile when _NO_OLDNAMES is defined, because it uses dev_t, ino_t, mode_t which are only available with an _ underscore prefix (_dev_t etc.) under _NO_OLDNAMES. For the FB rtlib we #define _NO_OLDNAMES when compiling.
To work around this issue, adjust wchar.h and add _ underscore prefixes to those typedef names in the struct _stat64 declaration.
Win32 rtlib compilation error: _controlfp, _PC_64 undeclaredThe wchar.h header file from MinGW.org contains a struct _stat64 declaration that does not compile when _NO_OLDNAMES is defined, because it uses dev_t, ino_t, mode_t which are only available with an _ underscore prefix (_dev_t etc.) under _NO_OLDNAMES. For the FB rtlib we #define _NO_OLDNAMES when compiling.
To work around this issue, adjust wchar.h and add _ underscore prefixes to those typedef names in the struct _stat64 declaration.
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.org runtime and GCC have a float.h header, and in some setups the GCC one is found before the MinGW one, causing the above errors.
Easiest temporary fix: Append #include_next <float.h> to gcc's float.h (C:\MinGW\lib\gcc\[target]\[version]\include\float.h)
See also:
- The comments at the top of C:\MinGW\include\float.h
- http://sourceforge.net/p/mingw/bugs/1580/
- http://sourceforge.net/p/mingw/bugs/1809/
- http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
fbc triggers a bug (binutils ld bug 12614) in the mentioned linker versions causing it to produce broken binaries in some cases. It's fixed in binutils 2.21.1 and up.
MinGW.org runtime's globbing code changes case of command line argumentshttp://sourceforge.net/p/mingw/bugs/2062/
MinGW.org's runtime (mingwrt-4.0.3) changed the case of command line arguments given to the program. If the argument matched an existing file/directory name and only differed in case, it was adjusted to match the exact spelling. This can cause problems with programs whose command line parsing is not case-insensitive. For example, gui became Gui if there was a directory called Gui. This affected fbc.exe's -s gui option, making it impossible to use, as fbc.exe refused to accept -s Gui.
-lXpm not found on Debian x86_64MinGW.org's runtime (mingwrt-4.0.3) changed the case of command line arguments given to the program. If the argument matched an existing file/directory name and only differed in case, it was adjusted to match the exact spelling. This can cause problems with programs whose command line parsing is not case-insensitive. For example, gui became Gui if there was a directory called Gui. This affected fbc.exe's -s gui option, making it impossible to use, as fbc.exe refused to accept -s Gui.
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:
DJGPP: Too many open filesln -s /usr/lib32/libXpm.so.4 /usr/lib32/libXpm.so
If a DJGPP program fails with a too many open files error on Windows, try the following to increase the number of available file handles:
- Use msconfig to add PerVMFiles=255 to the [386Enh] section of SYSTEM.INI
- Edit the files= setting in C:\WINDOWS\system32\CONFIG.NT: files=255
- Also see http://www.delorie.com/djgpp/v2faq/faq9_7.html