[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Wndows compile (was: [ANN] Lua 5.2.0 (work1) now available)
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Mon, 11 Jan 2010 19:02:35 +0100
2010/1/10 Enrico Colombini <email@example.com>:
> steve donovan wrote:
>> The problem here is that Windows uses a nasty preprocessor hack for
>> functions which have ASCII and Widechar variants. So there's a:
>> #define LoadString LoadStringA
>> in the headers, assuming this is a ASCII build.
>> So, #undef LoadString is one fix.
> Yes, it works (mingw32 on Dev-C++).
> I confess being unaware of this problem.
>> But surely camel-case identifiers
>> like this are not otherwise found in the Lua sources? Windows people
>> instinctively avoid them for the above reasons. Seems like a rename
>> would solve the problem cleanly.
> At the very least, renaming LoadString (lundump.c:75) to something else.
I may be mistaken, but I think some Windows flavours (like Windows CE)
provide only the unicode variant and don't use a suffix. On these
platforms LoadString not being a define but an actual imported
function name it may be more tricky to undef it. A rename in Lua
sources would ease things.