How should I handle character encoding when cross-compiling from Linux to Windows?

Question

How should I handle character encoding/conversion issues when cross-compiling from Linux to Windows using mingw?

---

I am attempting to cross-compile a Qt project on a Linux system for a Windows target. I've installed (what I believe to be) all the required mingw packages, and I think my environment is configured correctly. However, when I try to configure the Qt libraries, it fails when trying to compile project.cpp :

project.cpp: In member function 'QStringList& QMakeProject::values(const QString&, QMap<QString, QStringList>&)':
project.cpp:3062:51: error: cannot convert 'wchar_t*' to 'LPSTR {aka char*}' for argument '1' to 'WINBOOL GetComputerNameA(LPSTR, LPDWORD)'
gmake: *** [project.o] Error 1

I was able to hack around this single error by replacing wchar_t* with LPSTR in the code, but then I just ran into another error. It seems obvious that I am now facing a character encoding problem. I'm imagining that there might be some compiler options that would handle the conversion properly (I was looking at fexec-charset ), but I'm not even really sure about the problem. I understand that LPSTR and the like are Microsoft typedefs, but how should mingw handle them when cross-compiling from Linux for a Windows target?

Thanks!

---

Here is the offending lines of code from qmake/project.cpp:

DWORD name_length = 1024;
wchar_t name[1024];
if (GetComputerName(name, &name_length))
    ret = QString::fromWCharArray(name);

It seems GetComputerName is a macro which is being expanded to GetComputerNameA , when apparently I need GetComputerNameW .

Answer 1

By default, almost all Windows API functions (eg GetComputerName ) will resolve to the ANSI implementations (eg GetComputerNameA ) as opposed to their wide char variants (eg GetComputerNameW ).

Try #define UNICODE before your #include <windows.h> or pass the macro as an argument to your compiler.

For more info, see this and this .

Answer 2

You need to use the wide version of the WINAPI functions : GetComputerNameA becomes GetComputerNameW , etc.

Unicode versions (aka "wide") are suffixed with a W whereas ANSI version are suffixed with a A . They respectively accept LPWSTR and LPSTR as string arguments (LPWSTR being an alias for wchar_t*).

There also are macros which expand into one or the other depending on your unicode configuration. See the documentation of msdn for examples : GetComputerName .

Answer 3

You misconfigured Qt.

A correctly configured Qt build adds -DUNICODE -D_UNICODE (among a lot of other things) which remedies the problem you're experiencing.

Cross-compiling Qt is no fun task, nor is it easy to do correctly.