g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)
It looks like the implicit conversion from std::string to wxString isn't working. \u00a0That's used everywhere, the conversion needs to work.
wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. \u00a0You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.
It's probably some wxWidgets compile defines or build configuration. \u00a0What "configure" options did you use?
I'm not sure __WXMAC__ is the right define. \u00a0It may be the Mac Classic support that's complicating wxString, and we only want OSX. \u00a0Try __WXOSX__ (or see below)
"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:
\u00a0\u00a0 \u00a0* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.
\u00a0\u00a0 \u00a0* If you want to test for any GUI Mac port under OS X, use __WXOSX__.
\u00a0\u00a0 \u00a0* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__"