Re: [Mingw-users] [MinGW-users] _wfindnext64i32 not declared and other build errors

[Keith M. <kei...@us...>]

On 23/03/15 10:19, Jacob Hartmann wrote:
> Right, the developer of CEGUI has a few questions (as does myself).
> He wants to know if I am using 64 bit time, or 32 bit time. Now, I am
> not exactly sure how to check this, but my gut is saying something
> about build targets/architecture. Is this correct? He understands the
> situation as this: "the generic function should use 32 bit time but
> in your case it instead switches to use the 64 bit time version."

N.B. The following applies to the 32-bit builds provided by MinGW.org.
It may not apply to 64-bit builds, nor even to 32-bit builds from any
other source; such builds are not supported by MinGW.org, nor by this
mailing list.

If you read Microsoft's documentation, on MSDN, you will assume that
_wfindnext() uses 64-bit time, unless you define _USE_32BIT_TIME_T.
However, that documentation refers primarily to MSVC, and the runtime
DLLs on which it depends; today these are descendants of MSVCR80.DLL.
Thus, in respect of its applicability to MinGW, the validity of this
MSDN documentation is decidedly questionable.

> What could be wrong with my setup of Mingw, if I am using
> _wfindnext() and getting this error?

Your original posting said you were getting an unresolved symbol
reference for _wfindnext64i32(), which uses 64-bit time and 32-bit file
size fields.  However, this symbol was introduced in MSVCR80.DLL; it
does not appear in any version of MSVCRT.DLL, AFAIK.  Unless you jump
through several awkward hoops, your MinGW setup will link with
MSVCRT.DLL; it will *not* link with MSVCR80.DLL, nor any of its
descendants, (and simply adding -lmsvcr80 is *not* the way to change
this; doing so is asking for trouble).

If you are using a standard MinGW setup[*], if you use _wfindnext() that
is exactly the symbol your application should require; it should *not*
be trying to resolve it as _wfindnext64i32().  In MSVCRT.DLL, both
_wfindfirst() and _wfindnext() use 32-bit time and 32-bit file size;
Microsoft's _USE_32BIT_TIME_T nonsense seems to be irrelevant.

[*] Unless you have the badly broken mingwrt-4.x runtime.  If this is
the case you should get rid of it, and its w32api-4.x companion, as soon
as you possibly can; install mingwrt-3.21 and w32api-3.17 in their stead.

-- 
Regards,
Keith.