неопределенная функция strnlen (wxWidgets), когда программа компилируется с использованием другой версии gcc от cabal

Вот моя ситуация, я собрал wxWidgets 3.0 из исходного кода, используя TDM-GCC 4.8.1.
Тогда мы используем Хаскелла cabal система для сборки определенных пакетов, которые зависят от wx (например, wxHaskell), cabal вызывает его внутреннюю версию gcc для компиляции программ на C ++ (в моем случае /c/HaskellPlatform/2013.2.0.0/mingw/bin/gcc). Теперь версия gcc для cabal / Haskell генерирует ошибку компиляции в простой программе следующим образом:

#include <wx/wx.h>
int main() {}

Но компиляция в порядке при компиляции с gcc TDM-GCC (или когда gcc Haskell используется на wxWidgets, скомпилированных mingw32-gcc). Так что проблема в том, что cabal и MinGW используют разные версии gcc, и я не могу заменить gcc MinGW на gcc Haskell, потому что он старый (gcc 4.5.2 с Haskell Platform 2013.2). Также Haskell GCC называется realgcc.exe, и я даже не уверен, что он совместим с любым популярным дистрибутивом MinGW.

— подробности —

Сообщение об ошибке при компиляции вышеуказанной минимальной программы с использованием Haskell gcc:

D:\work\wxHaskell-wxwidgets-3.0.0\wxc>c:\HaskellPlatform\2013.2.0.0\mingw\bin\gc
c.exe -Wl,--hash-size=31 -Wl,--reduce-memory-overheads -Isrc/include -IC:/MinGW/
msys/1.0/local/include/wx-3.0 -IC:/MinGW/msys/1.0/local/lib/wx/include/msw-unico
de-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LARGEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTR
L -DBUILD_DLL -c src\cpp\apppath.cpp -o dist\build\src/cpp/apppath.o
In file included from C:/MinGW/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/MinGW/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/MinGW/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/MinGW/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/MinGW/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\apppath.cpp:1:
C:/MinGW/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/MinGW/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/MinGW/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/MinGW/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope

Я погуглил и некоторые предлагают добавить #include <cstring>;, Я добавил это к началу wxcrt.hи это не решило проблему.

Дело в том, что такая же ошибка компиляции для realgcc 4.5.2 не произошла бы, если бы я компилировал wxWidgets 3.0, используя mingw32 из mingw.org. (Но я сталкиваюсь с ошибками нарушения доступа к DLL по этому пути).

Мой вопрос почему realgcc признать strnlen а также wcsnlen если исходный код построен со стандартом MinGW32, но не получится, если исходный код скомпилирован с помощью TDM-GCC? И как мы можем взломать realgcc / mingw32 / tdm-gcc (или что-то еще), чтобы исправить эту ошибку?

Я знаю, что смешивать разные версии mingw / gcc опасно, но обычные пользователи не имеют большого выбора, поскольку системы сборки, такие как cabal, выбирают свои собственные компиляторы без консультации. Дополнительный вопрос, есть ли безопасный способ изменить программу GCC по умолчанию cabal использовать без разрыва клики?

Я использую TDM-gcc, потому что двоичные файлы TDM-GCC — это двоичные файлы, предоставляемые сопровождающими wxWidgets, и я думаю, что у этого больше шансов на успех. Я пытался cabal build WX с использованием MinGW-W64 GCC и получил исключения во время выполнения о cc1plus.exe во время компиляции. Считая проблему времени выполнения, о которой говорилось ранее о mingw32, переход с TDM-GCC, вероятно, является лучшим вариантом, как я понял.

— Обновить —

@icktoofay

Вот то, что я пробовал, похоже, не изменил компилятор gcc.

$ cabal configure —ghc-option = -pgmc —ghc-option = / c / mingw / bin / gcc.exe
Разрешение зависимостей …
Настройка wxc-0.90.1.1 …
Настройка wxc для сборки под wxWidgets 3.0

$ cabal build
Здание WXC
c: \ HaskellPlatform \ 2013.2.0.0 \ mingw \ bin \ gcc.exe -Wl, — hash-size = 31 -Wl, — уменьшить —

0

Решение

Я не могу сказать, почему вы получаете ошибку, но я могу рассказать вам, как изменить компилятор C, используемый Cabal и GHC. Это на самом деле GHC, который вызывает компилятор C и ищет в этот раздел руководства пользователя, мы нашли:

-pgmc cmd использование cmd как компилятор Си.

Вот как вы говорите GHC использовать определенный компилятор Си. Теперь вопрос в том, как заставить Кабала сказать GHC использовать этот компилятор Си. К счастью, В это же входит и руководство пользователя Cabal.:

--prog-options=options Укажите дополнительные опции к программе prog, Любая программа, известная Кабалу, может быть использована вместо prog, [ed: это означает, что GHC тоже!] […] --prog-option=option […]

Любой из них будет работать, как показывает документация. (Их поведение отличается, когда аргументы имеют пробелы.) Собрав все это, вы можете заставить Cabal и GHC использовать ваш предпочтительный компилятор C, например так:

> cabal configure --ghc-option=-pgmc --ghc-option=C:\path\to\gcc.exe
> cabal build

Если вы предпочитаете cabal install над configure/build, радуйся, ибо это работает с install, тоже. Если вы делаете это часто, вы можете рассмотреть возможность редактирования .cabal/config файл, чтобы изменить значение по умолчанию для использования предпочитаемого компилятора Си.

1

Другие решения

Других решений пока нет …