Cabal使用其他版本的gcc編譯程序時，未定義的strnlen函數（wxWidgets）

Question

這是我的情況，我使用TDM-GCC 4.8.1從源代碼構建了wxWidgets 3.0。 然后，我們使用Haskell的cabal系統構建某些依賴於wx的軟件包（例如wxHaskell）， cabal調用其內部版本的gcc來編譯C ++程序，（在我的情況下，是/c/HaskellPlatform/2013.2.0.0/mingw/bin/gcc ）。 現在，gcc的cabal / Haskell版本在一個簡單程序上生成了一個編譯錯誤，如下所示：

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

但是，在使用TDM-GCC的gcc進行編譯時（或在mingw32-gcc編譯的wxWidgets上使用Haskell的gcc時），編譯就可以了。 所以問題是， cabal和MinGW使用的gcc版本不同，並且我不能用Haskell gcc替換MinGW gcc，因為它很舊（從Haskell Platform 2013.2開始為gcc 4.5.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的開頭， wxcrt.h並不能解決問題。

事情是，如果我使用mingw.org的mingw32編譯wxWidgets 3.0，則不會發生針對realgcc 4.5.2的相同編譯錯誤。 （但是我通過該路徑遇到了DLL訪問沖突錯誤）。

我的問題是，如果源代碼是用標准MinGW32構建的，那么strnlen為什么realgcc識別strnlen和wcsnlen ，但是當用TDM-GCC編譯源代碼wcsnlen失敗了？ 以及我們如何破解realgcc / mingw32 / tdm-gcc（或其他）來修復此錯誤？

我知道混合使用不同版本的mingw / gcc是危險的，但是普通用戶在這里沒有太多選擇，因為Cabal之類的構建系統會在沒有咨詢的情況下選擇自己的編譯器。 另一個問題是，有沒有一種安全的方法可以在不破壞cabal的情況下更改默認的gcc程序cabal使用？

我使用TDM-gcc，因為TDM-GCC二進制文件是wxWidgets維護者提供的二進制文件，我認為這樣做成功的可能性更大。 我試圖使用MinGW-w64 gcc來cabal build wx，並在編譯期間遇到了有關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 Building wxc c：\\ HaskellPlatform \\ 2013.2.0.0 \\ mingw \\ bin \\ gcc.exe -Wl，-hash-size = 31 -Wl，-reduce-

Answer 1

我無法說出為什么會出現錯誤，但是我可以告訴您如何更改Cabal和GHC使用的C編譯器。 實際上是GHC調用了C編譯器， 在用戶手冊的這一部分中 ，我們發現：

-pgmc cmd使用cmd作為C編譯器。

因此，這就是告訴GHC使用某個C編譯器的方式。 現在的問題是如何讓Cabal告訴GHC使用該C編譯器。 幸運的是， Cabal的用戶手冊也涉及到這一點 ：

-- prog -options= options為程序prog指定其他選項。 Cabal已知的任何程序都可以代替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文件以更改默認值以使用首選的C編譯器。