> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT)
> >>Looks like it groks msys /include directory instead of mingw
> >>/mingw/include directory. Are you configuring with --prefix=/mingw ?
> >>Are there any possible --with-foo...=PREFIX arguments to
> Good idea, thanks, but there is no iconv header in the /mingw/msys/1.0/include (/include) directory, it is only in /mingw/include. The full path of the compiler error message is
> c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: error: unknown type name 'mbstate_t'
> ... which points to /mingw/include/iconv.h.
Something is broken in your system headers. mbstate_t is defined on
wchar.h, and iconv.h includes that header, at least on my system.
Perhaps your iconv.h is broken. Where did you get it?
Aaaahh. Nothing broken,this is the same
as on my system.
My iconv is from mingw-get install ...
libiconv (mingw32) and
msys-libiconv (msys, which I just now discovered, and which solved my libxslt
problem. So my bad, I guess if you install this, then iconv.h *is* in /include.)
So installing the msys-libiconv solved *that* problem. Now I just need to apply some patches (setjmp.h needs sigjmp_buf) supplied online. I guess iconv.h in /include doesn't use mbstate, and /include/wchar.h doesn't define it?
libiconv is also evidentally in minw32-libcharset & msys-libcharset, which I don't know if I need? And the msys-system-builder (meta) package, which I also don't have.
So I am still learning exactly when to use msys (apps for posix like env) and when to use mingw (win32 apps, right?). But nano.exe works in both, so?
Any problem solved.