xiph
MinGW build fails because `_wutime64()` is missing at some toolchains
Using some MinGW toolchains (Primarily official MinGW, not MinGW-w64) causes problems because of _wutime64() call is missing. A while ago I made the workaround and configure check to dodge this problem:
#ifdef HAVE_WUTIME64
# define FLAC_struct_utime __utimbuf64
# define FLAC_utime _wutime64
#else
# define FLAC_struct_utime _utimbuf
# define FLAC_utime _wutime
#endif
/* ... */
int utime_utf8(const char *filename, struct utimbuf *times)
{
wchar_t *wname;
struct FLAC_struct_utime ut;
int ret;
if (!(wname = wchar_from_utf8(filename))) return -1;
ut.actime = times->actime;
ut.modtime = times->modtime;
ret = FLAC_utime(wname, &ut);
free(wname);
return ret;
}
And I even sent a patch via mailing list, but no reply was taken, and I see the patch wasn't applied at all, and the problem is still here.
P.S. The source for _wutime64() call presence compile check I used at my custom builds:
#ifdef _WIN32
#undef NO_OLDNAMES
#undef _NO_OLDNAMES
#endif
#include <io.h>
#include <sys/utime.h>
#include <stdio.h>
#include <sys/stat.h>
#include <sys/utime.h>
#include <windows.h>
int main()
{
wchar_t *wname = L"dummy.txt";
struct __utimbuf64 ut;
ut.actime = 0;
ut.modtime = 0;
return _wutime64(wname, &ut);
}
Do you know why these toolchains do not provide these functions? Is there a specific reason or are these outdated? I'm unable to reproduce this, and that makes it difficult to write a patch for the autotools build system.
Look, I got reproduced it just now:
Wohlstand@WHL-VM-001 MINGW64 /c/Repos/flac/build (master)
$ cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/c/mingw-w64/Vanilla6.3/ ..
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Found Ogg: C:/mingw-w64/Vanilla6.3/include (found version "")
-- Found Iconv: C:/mingw-w64/Vanilla6.3/lib/libiconv.dll.a
-- Performing Test HAVE_MBSTATE
-- Performing Test HAVE_MBSTATE - Success
-- Performing Test DODEFINE_EXTENSIONS
-- Performing Test DODEFINE_EXTENSIONS - Success
-- Looking for byteswap.h
-- Looking for byteswap.h - not found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for arm_neon.h
-- Looking for arm_neon.h - not found
-- Looking for x86intrin.h
-- Looking for x86intrin.h - found
-- Looking for fseeko
-- Looking for fseeko - not found
-- Performing Test HAVE_BSWAP16
-- Performing Test HAVE_BSWAP16 - Success
-- Performing Test HAVE_BSWAP32
-- Performing Test HAVE_BSWAP32 - Success
-- Performing Test HAVE_LANGINFO_CODESET
-- Performing Test HAVE_LANGINFO_CODESET - Failed
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Searching 16 bit integer - Using unsigned short
-- Check if the system is big endian - little endian
-- Performing Test HAVE_WERROR_FLAG
-- Performing Test HAVE_WERROR_FLAG - Success
-- Performing Test HAVE_DECL_AFTER_STMT_FLAG
-- Performing Test HAVE_DECL_AFTER_STMT_FLAG - Success
-- Performing Test HAVE_STACKREALIGN_FLAG
-- Performing Test HAVE_STACKREALIGN_FLAG - Success
-- Performing Test HAVE_WEFFCXX_FLAG
-- Performing Test HAVE_WEFFCXX_FLAG - Success
-- Looking for __stack_chk_fail in ssp.a
-- Looking for __stack_chk_fail in ssp.a - found
-- Performing Test HAVE_STACK_PROTECTOR_FLAG
-- Performing Test HAVE_STACK_PROTECTOR_FLAG - Success
-- Looking for cpuid.h
-- Looking for cpuid.h - found
-- Looking for sys/param.h
-- Looking for sys/param.h - found
-- Looking for lround
-- Looking for lround - found
-- Check CPU architecture is x64
-- Check CPU architecture is x64 - no
-- Check CPU architecture is x86
-- Check CPU architecture is x86 - yes
-- Looking for a ASM_NASM compiler
-- Looking for a ASM_NASM compiler - NOTFOUND
-- Performing Test HAVE_MSSE2_FLAG
-- Performing Test HAVE_MSSE2_FLAG - Success
-- Looking for string.h
-- Looking for string.h - found
-- Found Intl: C:/mingw-w64/Vanilla6.3/include
-- Looking for sys/ioctl.h
-- Looking for sys/ioctl.h - not found
-- Looking for termios.h
-- Looking for termios.h - not found
-- Looking for clock_gettime
-- Looking for clock_gettime - not found
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find busybox, only basic tests are enabled
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Repos/flac/build
Wohlstand@WHL-VM-001 MINGW64 /c/Repos/flac/build (master)
$ ninja
[1/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/main.cpp.obj
[2/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/metadata.cpp.obj
[3/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/decoders.cpp.obj
[4/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/encoders.cpp.obj
[5/129] Building C object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/__/share/win_utf8_io/win_utf8_io.c.obj
FAILED: src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/__/share/win_utf8_io/win_utf8_io.c.obj
C:\mingw-w64\Vanilla6.3\bin\gcc.exe -DFLAC__NO_DLL -DHAVE_CONFIG_H -D_DARWIN_C_SOURCE -D_FORTIFY_SOURCE=2 -D_POSIX_PTHREAD_SEMANTICS -D_TANDEM_SOURCE -D__STDC_WANT_IEC_60559_BFP_EXT__ -D__STDC_WANT_IEC_60559_DFP_EXT__ -D__STDC_WANT_IEC_60559_FUNCS_EXT__ -D__STDC_WANT_IEC_60559_TYPES_EXT__ -D__STDC_WANT_LIB_EXT2__ -D__STDC_WANT_MATH_SPEC_FUNCS__ -I../include -I. -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wnested-externs -Wshadow -Wundef -Wmissing-declarations -Winline -O3 -DNDEBUG -O3 -funroll-loops -Wdeclaration-after-statement -fstack-protector-strong -MD -MT src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/__/share/win_utf8_io/win_utf8_io.c.obj -MF src\test_libFLAC++\CMakeFiles\test_libFLAC++.dir\__\share\win_utf8_io\win_utf8_io.c.obj.d -o src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/__/share/win_utf8_io/win_utf8_io.c.obj -c ../src/share/win_utf8_io/win_utf8_io.c
../src/share/win_utf8_io/win_utf8_io.c: In function 'utime_utf8':
../src/share/win_utf8_io/win_utf8_io.c:315:21: error: storage size of 'ut' isn't known
struct __utimbuf64 ut;
^~
../src/share/win_utf8_io/win_utf8_io.c:321:8: warning: implicit declaration of function '_wutime64' [-Wimplicit-function-declaration]
ret = _wutime64(wname, &ut);
^~~~~~~~~
../src/share/win_utf8_io/win_utf8_io.c:321:2: warning: nested extern declaration of '_wutime64' [-Wnested-externs]
ret = _wutime64(wname, &ut);
^~~
../src/share/win_utf8_io/win_utf8_io.c:315:21: warning: unused variable 'ut' [-Wunused-variable]
struct __utimbuf64 ut;
^~
[6/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/metadata_object.cpp.obj
[7/129] Building CXX object src/test_libFLAC++/CMakeFiles/test_libFLAC++.dir/metadata_manip.cpp.obj
ninja: build stopped: subcommand failed.
Wohlstand@WHL-VM-001 MINGW64 /c/Repos/flac/build (master)
$ gcc --version
gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Now I try to take the updated MinGW toolchain from here: https://osdn.net/projects/mingw/ (It's the original MinGW toolchain)
So:
- with MinGW-w64 toolchains all works fine.
- with the original MinGW toolchains there is a problem with the
_wutime64call. Checked just now, and the problem is the same.
I do not understand. Does not minGW emulate this stuff on windows? Glibc is absent on windows, unless you install that genious git compiled that brings whole coreutils which is somehow very nice level of GMP library stuff in factor.exe command e.g, even Debian did not enable it yet!
What I mean if it emulates, then you are supposed to always use latest version with all the stuff. Because otherwise you will make MacOS and other linux worse, including Android. And ifdef is a hack.
AppVeyor images and with some 32-bit toolchains
You are not supposed to build with either of this. 32 bit windows is deprecated since version 11 and AppVeyor is for our internal use.
I do not understand. Does not minGW emulate this stuff on windows?
There are two different MinGW editions:
- The original MinGW is the first and initial branch of MinGW that existed in the history
- The MinGW-w64 is a different implementation of MinGW that branched off the original MinGW implementation with a goal to make a more accurate WinAPI environment including lots of stuff that was absent at the original MinGW, including the 64-bit support. At some moment they attempted to backport all stuff into the original MinGW but got been rejected because the original team afraid of the possible presence of non-free or proprietary stuff at MinGW-w64.
Both branches exist and developing by their teams independently.
And my report is about the original MinGW branch, where their headers have missing definitions of __utimbuf64 and related stuff. MinGW-w64 branch is valid and allows for the building of both 32bit and 64bit programs normally.
You are not supposed to build with either of this. 32 bit windows is deprecated since version 11 and AppVeyor is for our internal use.
The 32-bit is needed for users who still use such hardware (right now is not so often as like was in the past), but I know several people who use the next cases:
- Real 32-bit hardware and 32-bit OS (very rare case, often running the old OS on old hardware for experiments or for old games, etc. I have such hardware in my own collection, and I do various tests on it, basically to verify the performance in a real environment of weaker hardware). As I know, the last time where real 32-bit hardware was manufactured, were based on the Intel Atom thing, manufactured up to 2013.
- 32-bit OS installed over 64-bit hardware (By silliness of the owner, or because it contains not enough resources, like 2 GB RAM or lesser, I have a friend who owns such laptop and can't normally use 64-bit OS)
- 32-bit OS on 64-bit hardware that has only a 32bit bootloader and ruins the ability to use 64bit (there are some models of tablets, one of them noticed by my buddy)
- 32-bit OS installed over 64-bit hardware
Well, technically you can bypass OS and still run 64 bit instructions on 32 bit OS and in 32 bit APP, you only need 64 bit CPU. It is hard, but possible. So bad example. Google "Heaven's Gate".
This? https://github.com/dadas190/Heavens-Gate-2.0 Interesting... I'll send this to my buddy who works on some hacking stuff over an old game
This?
Yes, but that still uses NT kernel API, that Microsoft calls Heaven's gate. I am talking ahout actually attacking the kernel and getting access to CPU hyperviser style.
@ktmf01, ping? I researched the case and I confirm that failure happens on the official MinGW, not on MinGW-w64 where it builds fine.
There are two different MinGW editions:
* The original [MinGW](https://osdn.net/projects/mingw/) is the first and initial branch of MinGW that existed in the history * The [MinGW-w64](https://www.mingw-w64.org/) is a different implementation of MinGW that branched off the original MinGW implementation with a goal to make a more accurate WinAPI environment including lots of stuff that was absent at the original MinGW, including the 64-bit support. At some moment they attempted to backport all stuff into the original MinGW but got been rejected because the original team afraid of the possible presence of non-free or proprietary stuff at MinGW-w64.Both branches exist and developing by their teams independently.
Just to make sure: the MinGW you're referring to hasn't had a release in almost 9 years, correct? Why would one still want to use this over MinGW-w64?
hasn't had a release in almost 9 years
Where did you see it was 9 years ago? They had moved to osdn.net for some moment, and they are still active as I see.
I just installed it and it says 'version 2013072300' everywhere. However, I see many packages are indeed newer, so never mind. I'll look into this.
I can't reproduce this problem with either CMake or autotools with the mingw toolchain I got from OSDN.net. Everything builds just fine here.
I tried to find something about _wutime64 in the mingw sources, and it seems it has been there for quite some time. There are fixes related to it that date back to 2018. See here, the entry for 2018-02-22. It says
2018-02-22 Keith Marshall <[email protected]>
Correct Windows version support for <utime.h> functions.
[...]
Implement them in-line, delegating each respectively to...
[_USE_32BIT_TIME_T] (_utime32, _wutime32, _futime32): ...these, or...
[!_USE_32BIT_TIME_T] (_utime64, _wutime64, _futime64): ...to these.
Could you check whether this is also the case on your end?
@Wohlstand Have you had the time to try this yet? I've tried again today (I wasn't sure whether I used CMake like you did in your example) but couldn't replicate
Not yet, I was busy, I will need to try a clear installation from the scratch to ensure the pure environment of original MinGW (https://osdn.net/projects/mingw/) installed from the scratch. My environment is old and contains that damned bug (for which I made the workaround). I work on Linux Mint mainly, and I rarely use Windows VMs to debug various stuff. And, that bug is presented in several AppVeyor CI environments because of old MinGW usage.