premake/README-cygwin.txt
author Sam Lantinga <slouken@libsdl.org>
Fri, 28 Nov 2014 04:51:33 -0800
changeset 9246 a761913e5e91
parent 7925 f090a47eb7f7
permissions -rwxr-xr-x
Fixed bug 2786 - "UCS-2-INTERNAL" iconv encoding is not supported everywhere, use UTF-16LE instead

Jonas Kulla

src/main/windows/SDL_windows_main.c:137:
cmdline = SDL_iconv_string("UTF-8", "UCS-2-INTERNAL", (char *)(text), (SDL_wcslen(text)+1)*sizeof(WCHAR));

I'm trying to compile an SDL2 application for windows using the mingw-w64 32bit toolchain provided by my distro (Fedora 19). However, even the simplest test program that does nothing at all fails to startup with a "Fatal error - out of memory" message because the mingw iconv library provided by my distro does not support the "UCS-2-INTERNAL" encoding and the conversion returns null.

From my little bit of research, it turns out that even though this encoding is supported by the external GNU libiconv library, some glibc versions (?) don't support it with their internal iconv routines, and will instead provide the native endian encoding when "UCS-2" is specified.

Nonetheless, I wonder why the native endianness is considered in the first place when Windows doesn't even run on any big endian archs (to my knowledge). And true enough, 'WIN_StringToUTF8' from core/windows/SDL_windows.h is used everywhere else in the windows backend, which is just a macro to iconv with "UTF-16LE" as source. Therefore it would IMO make sense to use this macro here as well, which would solve my problem (patch attached).
     1 There is a script in the Cygwin/build-scripts folder for generating a series of
     2 GNU makefiles for building the SDL2 project and some parts of its test suite.
     3 These work similarly to the MinGW makefiles, but the overall Cygwin project has
     4 significant limitations.
     5 
     6 The current project will not build correctly. It's experimental and has a lot of
     7 tweaking needed to be built. It was built successfully once, but it has not been
     8 maintained in any way.
     9 
    10 The Cygwin project is limited in that it is not expected to be able to run
    11 anything visual at all. It is not difficult to enable all of the visual tests
    12 and support (such as X11 support or OpenGL), but it is not a goal for this
    13 project. For the complexity of having a compatible desktop environment setup on
    14 Cygwin, it's assumed that will not be the case for most users of the generated
    15 Cygwin project. As a result, only the core tests and library are built for
    16 Cygwin, focusing on things like thread support, file operations, and various
    17 system queries and information gathering.
    18 
    19 The Cygwin directory does have automated tests to run through the tests
    20 supported by Cygwin. It also has separate build scripts for both debug and
    21 release builds, though this is assuming the GNU make utility is located in the
    22 user's PATH.
    23 
    24 The Cygwin project has no outstanding dependencies, since it is designed to be
    25 mostly minimalistic and just relied on the POSIX functionality provided by
    26 Cygwin.
    27 
    28 Like the other projects, you may cleanup the entire directory of any generated
    29 or built files using the clean script located in Cygwin/build-scripts.