compile SDK sample source with GCC on linux

Hi all,
I've been trying to compile the sample sources included with the SDK on Linux with the arm-mingw32ce-gcc. In order to prepare the SDK's files for compilation in a case-sensitive environment, I first converted all files and all references to files (#include) to lowercase. Also I've changed the encoding from GB2312 to UTF8 (so that one can still read the Chinese comments) and exchanged the Windows-only backslash notation for include paths to the more general forward slash notation.

When compiling with the strict GCC, some stylistic errors in the SDK files became obvious (like so-called "extra qualifications" in classes), which could be fixed manually. Furthermore, the SAL annotations to methods (__in, __out and __inout) are not supported by GCC, and had to be stripped off the code.

The compiler also complained about missing definitions of std:wstring and the _T macro. Including "tchar.h" and <string> was enough to appease the compiler.
Sadly, I have not yet managed to compile the first example 01_hellomzfc.cpp, due to two remaining problems:

- the library mzfc.lib was compiled with VS2005 and uses a different exporting scheme than expected by the GCC-linker
- the macro MZ_INITIALIZE_DYNAMICALLY (in mzuser.h) makes use of the "L" attribute, which is not defined in the scope of that macro (leading to invalid preprocessor directives)

Does anyone know...
... how to make a VS2005-lib work with GCC?
... how to define L (for unicode conversion) in mzuser.h to make the macro MZ_INITIALIZE_DYNAMICALLY work?

Attached is the cleanup-script that performs the above-mentioned conversions and my currently-used makefile.

NOTE: I use the include files of the mingw32ce-compiler instead of the files in the include/armv4i directory except for ddraw.h, which doesn't exist in the compiler package
NOTE: the sub-directory "missing" contains the following files: ddraw.h, mzfc.lib, mzfc.exp, mzfcsd.lib, platformapi.lib

I've been trying to convert the libraries mzfc.lib and mzfcsd.lib by listing all their symbols in a definition file (mzfc.def and mzfcsd.def) and let the tool dllimport operate on these definitions. It did write out a library in the format lib<name>.a, but the linker still doesn't seem to find the library during compilation ("undefined reference...").


In case someone is interested: I just created a new thread in the developer forum of the official Meizu forum:
http://bbs.meizu.com/viewthread.php?...%3D1&frombbs=1

The reason for the linker failure is that the import libraries delivered with the SDK (those *.lib files with the same name as their dll-originals) are not compatible with any other compiler/linker-package than with MSVC.
It is possible to generate import libraries for use with the MinGW/GCC package by using a combination of nm and dlltool. However, this failed in my tests as all DLLs are stripped, i.e. there are no symbols left to reconstruct the function enty points.

Unless Meizu delivers unstripped DLLs, the only possibility to link to the libraries is to create object stubs; i.e. each header file gets one remodelled and useless cpp file. Then the cpp+h packages have to be compiled to objects. Finally, one can run nm and dlltool on them to create an import library to link against.

I'm currently working on a ruby script that does all that automatically. If somebody'd like to experiment with it, please let me know.