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

0

Вот моя ситуация, я построил wxWidgets 3.0 из источника, используя TDM-GCC 4.8.1. Тогда мы я использую 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 (или когда Haskell gcc используется на скомпилированных wxWidgets из mingw32-gcc) компиляция в порядке. Поэтому проблема в том, что cabal и MinGW используют разные версии gcc, и я не могу заменить MinGW gcc на Haskell gcc, потому что он старый (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

Я googled вокруг, и некоторые предлагают добавить #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
    Как я уже писал в ответ на ваш другой вопрос , вам действительно нужно посмотреть config.log чтобы увидеть, что происходит.
  • 0
    @VZ Я не уверен, что вы говорите в этом посте, как и в других о config.log. В любом из ваших комментариев действительно мало информации. Слепое голосование за правильные вопросы, в то время как утверждение проблемы с пользователем всегда смешно в обоих случаях.
Показать ещё 4 комментария
Теги:
haskell
cabal
wxwidgets

1 ответ

1

Я не могу сказать, почему вы получаете сообщение об ошибке, но я могу сказать вам, как использовать C-компилятор C, используемый Cabal и GHC. Фактически 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

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

  • 0
    Большое спасибо за ваш ответ. Я пытался, как вы предложили, но это не изменило компилятор. Пожалуйста, смотрите обновление. Я что-то пропустил?
  • 0
    @TingL: имейте в виду, что GHC работает изначально, а не под MinGW, поэтому вам придется использовать пути Windows, такие как C:\path\to\gcc.exe , а не /c/path/to/gcc.exe .
Показать ещё 4 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню