Closed chris-se closed 8 months ago
Yes, I also noticed recently that it is broken, see my similar change here: https://github.com/modelica/ModelicaStandardLibrary/pull/4285/files#diff-fd202881aff26f5dd968dfcd19796cb461c19bf5d3f35ebc30a40b3e1d531a65R276
Regardless, I'll be happy to provide a pull request fore the above patch if you agree with this solution.
That would be appreciated. Thanks.
Regardless, I'll be happy to provide a pull request fore the above patch if you agree with this solution.
That would be appreciated. Thanks.
Done, thanks: https://github.com/tbeu/matio/pull/235
Resolved by #235. Thanks.
LFS support on MinGW is currently somewhat broken (MinGW, x86_64, CMake build system). Since MinGW defines all of
fseeko
,ftello
,fseeko64
,ftello64
,_fseeki64
, and_ftelli64
, and also the compile time constant__MINGW32__
, the following sequence inmingw_private.h
has some interesting results:Since
__MINGW32__
is defined, the compiler will go into the first#if
condition and execute#define mat_off_t __int64
. But none of the nested#if
s apply to MinGW: the first (defined(_MSC_VER) && defined(HAVE__FSEEKI64) && defined(HAVE__FTELLI64)
) because_MSC_VER
is not defined, the second (defined(__BORLANDC__) && defined(HAVE__FSEEKI64) && defined(HAVE__FTELLI64)
) because__BORLANDC__
is not defined, and the third (!defined(HAVE_FSEEKO) && !defined(HAVE_FTELLO) && defined(HAVE_FSEEKO64) && defined(HAVE_FTELLO64)
) becauseHAVE_SEEKO
andHAVE_FTELLO
are defined (but also the 64bit counterparts).But that means that
MATIO_LFS
is never defined, and the bottom#if !defined(MATIO_LFS)
is also entered. That contains#define mat_off_t long
. This has the consequence on MinGW that the compiler issues the following warnings:Note though that
long
is 32bit on MinGW, even on 64bit platforms (since Win64 longs are 32bit)! This means that even on 64bit Windows, matio will use 32bit offsets!I've tested the following patch and works on MinGW, as well as Linux and macOS:
Notes:
#define mat_off_t __int64
into the inner conditions to ensure that the double-#define
never happens again. (Even if no inner condition is matched.)!defined(HAVE_FSEEKO) && !defined(HAVE_FTELLO)
from the#elif
condition, because that doesn't make any sense in my eyes.This is minimally invasive, and hopefully shouldn't cause breakage on other systems, but I'm sure the entire logic here could probably be refactored in a better manner.
Regardless, I'll be happy to provide a pull request fore the above patch if you agree with this solution.