libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -fPIC -Wall - >I/usr/local/lib/wx/include/gtk2-unicode-3.0 -I/usr/local/include/wx-3.0 ->D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -DWXGTK -pthread -D_SAGA_LINUX -D_SAGA_UNICODE ->D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_API_EXPORTS -fopenmp -g -O2 -MT api_string.lo -MD >-MP -MF .deps/api_string.Tpo -c api_string.cpp -fPIC -DPIC -o .libs/api_string.o
api_string.cpp: In member function 'const char CSG_String::b_str() const':
api_string.cpp:253:21: error: cannot convert 'wxString' to 'const char' in return
return( *m_pString );

To get a char*, I would expect something like m_pString->c_str()

Changing this one instance cause compilation to fail on similar string conversions

OpenSuse 13.1
wxWidgets 3.0
Saga trunk or 2.1.1 tarball
gcc 4.8.1

Hi,

do you have installed several wx versions in parallel? Seems to me that you are picking up header files from an older wx version. Could you please verify that you don't have conflicting wx-lib and wx-dev packages? What is reported by

wx-config --selected-config

wx-config --selected-config reports
gtk2-unicode-3

This box has libs for wx 2.8 but no headers (-devel package not installed)

wxWidgets 3.0 was installed from source.

Looking at the wxString docs http://docs.wxwidgets.org/stable/classwx_string.html shows the following conversions...
Similarly, wxString can be converted to:
* ASCII string using wxString::ToAscii(). This is a potentially destructive operation as all non-ASCII string characters are replaced with a placeholder character.
* String in the current locale encoding implicitly or using c_str() or mb_str() methods. This is a potentially destructive operation as an empty string is returned if the conversion fails.
* String in UTF-8 encoding using wxString::utf8_str().
* String in any given encoding using mb_str() with the appropriate wxMBConv object. This is also a potentially destructive operation.
* Standard std::string using wxString::ToStdString(). The contents of the returned string use the current locale encoding, so this conversion is potentially destructive as well.
* Wide C string using wxString::wc_str().
* Standard std::wstring using wxString::ToStdWstring().

BUT, there is also this:

Note
If you built wxWidgets with wxUSE_STL set to 1, the implicit conversions to both narrow and wide C strings are disabled and replaced with implicit conversions to std::string and std::wstring.

I will look into whether wxUSE_STL was set. Personally, using an implicit conversion from string class to C string sounds both convenient and slightly evil. I expect this the source of the problem here.

That may explain the issue you are observing, I've found the following reference to the usage of STL:

http://www.wxwidgets.org/docs/faqgen.htm#stl

Other projects (e.g. Codeblocks) also advise against the usage of STL, as this would require to patch their source code:

http://forums.codeblocks.org/index.php?topic=11091.0;wap2

Please report back in case you make any findings.

SAGA 2.1.1 builds with wxgtk 3.0.0 when wxgtk is built without the --enable-stl flag. It's what I noticed on Arch Linux 64bit.

The package maintainer for wxgtk 3 on Arch won't be able to remove the --enable-stl flag from the build.

Does anyone know if it's possible to build saga when either of these options is tried?

You can work around it either by switching off memory checking, or by adding this to a header before you include any STL files:

#ifdef new
#undef new
#endif

Maybe turning off memory checking while building would be easier than patching headers? Not sure how to turn off memory checking or even what that is.

I am wondering which software requires a wxgtk package built with --enable-stl as this seems quite uncommon? At least on other distros this does not seem to be the "default" and I would expect numerous other softwares besides SAGA that require a standard build.

I'm afraid that the workaround is not that easy as SAGA relies on special options provided by wxString. So I think it is not about including STL in SAGA but the missing wxString functionality in std::string.

Looks like it's GRASS that needed the --enable-stl in wxgtk or GRASS documentation fails in the GRASS build (because of wxpython).

But I found where I went wrong and now both GRASS and SAGA GIS are working after rebuilding wxpython and wxpython2.8 against my rebuilt wxgtk (without --enable-stl). Just had to keep chasing the packages down the dependency chain for both SAGA/GRASS.

If it helps anyone else in this process, I was able to get saga 2.1.1 to compile and run on a fresh archlinux install.
Here are the steps that worked for me.

1. Rebuild wxgtk (3.0) without the --enable-stl flag. (Thanks saultdon)
   -- To rebuild a package in archlinux as root, follow the steps here : https://wiki.archlinux.org/index.php/ABS_FAQ#Can_I_get_a_copy_of_the_PKGBUILD_files_that_the_Arch_Linux_developers_use.3F
   # pacman -S abs
   # abs
   #cd ~
   #mkdir mywxgtk
   #cp -r /var/abs/extra/wxgtk ~/mywxgtk
   -- In ~/mywxgtk/wxgtk edit PKGBUILD and delete --enable-stl
   -- Now rebuild wxgtk without that --enable-stl flag
   # makepkg
   -- And finally install it
   # pacman -U wxgtk-3.0.0-2-x86_64.pkg.tar.xz

2. From here I downloaded the linux source for saga 2.1.1, but the compiler errors out looking for projects.h.
   See http://sourceforge.net/p/saga-gis/bugs/145/
   -- So, I had to manually find the "projects.h" file in the proj4 source.
   -- Download http://download.osgeo.org/proj/proj-4.8.0.tar.gz and copy the projects.h file from it.
   -- Paste projects.h into the saga source folder saga-2.1.1/src/modules_projection/pj_proj4/pj_proj4
   -- now compile saga using the standard flow
   $./configure --enable-unicode
   $make
   $sudo make install
   -- hopefully saga_gui will work for you

All of the steps listed were from this and other threads, but it might be useful to go through them all here.
Again, this was on a clean install.