Известные проблемы при компиляции FB
Win32 rtlib compilation error: wchar.h: unknown type name 'dev_t'
http://sourceforge.net/p/mingw/bugs/2039/
Файл заголовка wchar.h из MinGW.org содержит декларацию struct _stat64 , которая не компилируется, когда _NO_OLDNAMES объявлен, потому что он использует dev_t, ino_t, mode_t которые доступны только с _ префиксом подчеркивания (_dev_t etc.) под _NO_OLDNAMES. Для FB rtlib мы объявили #define _NO_OLDNAMES при компиляции.
Чтобы обойти эту проблему, необходимо настроить wchar.h и добавить _ префиксы подчеркивания для этих typedef имен в декларации struct _stat64.
Win32 rtlib compilation error: _controlfp, _PC_64 undeclaredФайл заголовка wchar.h из MinGW.org содержит декларацию struct _stat64 , которая не компилируется, когда _NO_OLDNAMES объявлен, потому что он использует dev_t, ino_t, mode_t которые доступны только с _ префиксом подчеркивания (_dev_t etc.) под _NO_OLDNAMES. Для FB rtlib мы объявили #define _NO_OLDNAMES при компиляции.
Чтобы обойти эту проблему, необходимо настроить wchar.h и добавить _ префиксы подчеркивания для этих typedef имен в декларации struct _stat64.
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)
Оба MinGW.org runtime и GCC имеют заголовк float.h, и в некоторых установках GCC один находится перед первым MinGW, вызывая выше ошибки.
Простое временное исправление: Добавить #include_next <float.h> в gcc float.h (C:\MinGW\lib\gcc\[target]\[version]\include\float.h)
Смотрите также:
- Комментарии в верхней части 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 вызывает ошибку (binutils ld bug 12614)
в версиях указанного компоновщика, заставляя его производить
сломанные двоичные файлы в некоторых случаях. Это исправлено в binutils 2.21.1
и выше.
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) изменены опции аргументов командной строки для программы. Если аргумент соответствует существующему имени файла/папки и только отличались в опции, это была скорректировано, чтобы соответствовать точному написанию. Это может вызвать проблемы с программами, командная строка которых не чувствительна к регистру. Для примера, gui стал Gui если бы был каталог с именем Gui. Это скажется на опции fbc.exe -s gui, что сделает невозможным использование, так как fbc.exe откажется принимать -s Gui.
-lXpm not found on Debian x86_64MinGW.org's runtime (mingwrt-4.0.3) изменены опции аргументов командной строки для программы. Если аргумент соответствует существующему имени файла/папки и только отличались в опции, это была скорректировано, чтобы соответствовать точному написанию. Это может вызвать проблемы с программами, командная строка которых не чувствительна к регистру. Для примера, gui стал Gui если бы был каталог с именем Gui. Это скажется на опции fbc.exe -s gui, что сделает невозможным использование, так как fbc.exe откажется принимать -s Gui.
Пакет ia32-libs-dev (например, на Debian 6) по какой-либо
причине не содержит /usr/lib32/libXpm.so символьной
ссылки, даже если он содержит для других X11 библиотек. Это,
по-видимому, может быть исправлено путем создания символической
ссылки вручную:
DJGPP: Too many open filesln -s /usr/lib32/libXpm.so.4 /usr/lib32/libXpm.so
Если программа DJGPP завершается с too many open files error
на Windows, попробуйте следующее,
чтобы увеличить количество доступных файловых дескрипторов:
- Используйте msconfig чтобы добавить PerVMFiles=255
в [386Enh] секцию SYSTEM.INI
- Отредактируйте files= настройки в C:\WINDOWS\system32\CONFIG.NT: files=255
- Также смотрите http://www.delorie.com/djgpp/v2faq/faq9_7.html