premake/README-ios.txt
author Sam Lantinga <slouken@libsdl.org>
Fri, 28 Nov 2014 04:51:33 -0800
changeset 9246 a761913e5e91
parent 8921 4a9feef61c85
child 9876 1496e502e51d
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).
icculus@7925
     1
Use the Xcode command files (located in the Xcode-iOS/build-scripts folder)
icculus@7925
     2
to conveniently generate a workspace for Xcode 3 or Xcode 4. It also
icculus@7925
     3
contains a cleaner script and a convenient script for automatically
icculus@7925
     4
running all the test suites.
icculus@7925
     5
icculus@7925
     6
The iOS project will be referencing all files related to the top-level iOS
icculus@7925
     7
project. The core library will use the top-level include and src directories,
icculus@7925
     8
just like the other generated projects, but it will build projects for each of
icculus@7925
     9
the Demos in the top-level Xcode-iOS folder. These projects will have any
icculus@7925
    10
resources they need copied to be copied over and included as resources. They
icculus@7925
    11
will also reference the Info.plist file in Xcode-iOS/Demos.
icculus@7925
    12
icculus@7925
    13
iOS support is currently experimental, but it should work just fine for any and
icculus@7925
    14
all applications. All of the demos that work from the manually-created Xcode
icculus@7925
    15
projects also work for the generated projects. There are a few minor things that
icculus@7925
    16
need improving, but nothing major.
icculus@7925
    17
icculus@7925
    18
The iOS projects have no major dependencies other than the ones in the manual
icculus@7925
    19
Xcode-iOS project. Those are:
icculus@7925
    20
icculus@7925
    21
  -AudioToolbox.framework
icculus@7925
    22
  -QuartzCore.framework
icculus@7925
    23
  -OpenGLES.framework
icculus@7925
    24
  -CoreGraphics.framework
icculus@7925
    25
  -UIKit.framework
icculus@7925
    26
  -Foundation.framework
icculus@7925
    27
  -CoreAudio.framework
slouken@8921
    28
  -CoreMotion.framework
icculus@7925
    29
icculus@7925
    30
All of these frameworks are part of the iOS SDK, not part of the core OS X
icculus@7925
    31
system.
icculus@7925
    32
icculus@7925
    33
Run the clean script to clear out the directory of Xcode-related files
slouken@8921
    34
and binaries.