Some canonical types not defined with macro '__STRICT_ANSI__' or gcc option '-std=c99'
file conftest.c:
#include <sys/types.h>
#include <unistd.h>
==== test 1 ====
gcc -c -O2 -pipe -W -Wall -std=c99 -pedantic -o conftest1.o conftest.c
In file included from d:\mingwoff\include\unistd.h:36:0,
from conftest.c:3:
d:\mingwoff\include\io.h:301:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
d:\mingwoff\include\io.h:301:36: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
d:\mingwoff\include\io.h:302:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
d:\mingwoff\include\io.h:302:39: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
In file included from conftest.c:3:0:
d:\mingwoff\include\unistd.h:65:20: error: unknown type name 'off_t'
int ftruncate(int, off_t);
^
d:\mingwoff\include\unistd.h:67:38: error: unknown type name 'off_t'
__CRT_INLINE int ftruncate(int __fd, off_t __length)
==== test 2 ====
gcc -c -O2 -pipe -W -Wall -std=c99 -pedantic -U__STRICT_ANSI__ -o conftest2.o conftest.c
OK.
==== test 3 ====
gcc -c -O2 -pipe -W -Wall -std=c99 -o conftest3.o conftest.c
In file included from d:\mingwoff\include\unistd.h:36:0,
from conftest.c:3:
d:\mingwoff\include\io.h:301:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
d:\mingwoff\include\io.h:301:36: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int, off64_t, int);
^
d:\mingwoff\include\io.h:302:1: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
d:\mingwoff\include\io.h:302:39: error: unknown type name 'off64_t'
__CRT_INLINE off64_t lseek64 (int fd, off64_t offset, int whence) {
^
In file included from conftest.c:3:0:
d:\mingwoff\include\unistd.h:65:20: error: unknown type name 'off_t'
int ftruncate(int, off_t);
^
d:\mingwoff\include\unistd.h:67:38: error: unknown type name 'off_t'
__CRT_INLINE int ftruncate(int __fd, off_t __length)
==== test 4 ====
gcc -c -O2 -pipe -W -Wall -pedantic -o conftest4.o conftest.c
OK
==== test 5 ====
gcc -c -O2 -pipe -W -Wall -std=gnu99 -pedantic -o conftest5.o conftest.c
OK
$ gcc -v
Using built-in specs.
COLLECT_GCC=d:\mingwoff\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/mingwoff/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)
$ ld -v
GNU ld (GNU Binutils) 2.23.2
mingwrt-4.0.3
In mingw32-w64 this tests are passed.
P.S. Sorry bad english...
Sorry, bad formatting.
file conftest.c:
Diff:
Hmm. What do you mean by "canonical types"?
off64_tis not an ANSI type, so it's correct that it should not be defined -- unless the user furnishes the typedef -- when__STRICT_ANSI__conformity checking is specified.The bug here is that inclusion of unistd.h -- itself not an ANSI header -- should then gratuitously expose declarations -- via io.h, apparently -- which assume that such types will be defined. But, surely this is a duplicate of [#2046], (which has been marked as fixed)?
Related
Issues: #2046
__STRICT_ANSI__Ok, my description of this bug incorrect, but how this test passed in mingw-w64 and native linux?
I'm trying to compile in msys & mingw 'nasm' and take this error in configure phase.
Bug in nasm?
Ok, I read about bug #2046, this may be closed. Sorry for duplication.
What about #2201?