Overview: While trying to compile GCC with an old release of Mingw headers (2.4), I got a stop in libcpp, trying to use ssize_t which was not typedef'd.
Steps to reproduce: - grab an old-fashionned, non-POSIX, environment - ./configure && ./make all-gcc - go out for lunch if the hardware matches the software :-) Actual results: While building, one can notice (this is inside gcc/gcc): ... Configuring in ./gcc ... checking for putc_unlocked... no checking whether mbstowcs works... yes checking for ssize_t... no checking for uid_t in sys/types.h... no checking type of array argument to getgroups... int ... Configuring in ./libcpp ... gcc -I/l/src/gcc/libcpp -I. -I/l/src/gcc/libcpp/../include -I/l/src/gcc/libcpp/include -D__USE_MINGW_ACCESS -O2 -g0 -s -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -I/l/src/gcc/libcpp -I. -I/l/src/gcc/libcpp/../include -I/l/src/gcc/libcpp/include -c -o files.o -MT files.o -MMD -MP -MF .deps/files.Po /l/src/gcc/libcpp/files.c l:/src/gcc/libcpp/files.c: In function `read_file_guts': l:/src/gcc/libcpp/files.c:568: error: `ssize_t' undeclared (first use in this function) ... make[1]: *** [files.o] Error 1 make[1]: Leaving directory `/home/ANTOINE/gcc/libcpp' make: *** [all-libcpp] Error 2 Expected Results: no such error :-) Build Date & Platform: GCC from SVN (130488) Build env. is Mingw 2.4 inside Msys 1.10, GCC 3.4.2, a few prebuilt tools&libraries like bison/GMP/MPFR System: MINGW32_NT-5.0 ANTOINE 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown Host tools (for reference) are binutils 2.18.50, the target include/ are from SVN of mingw-w64.sf.net (220) Additional Builds and Platforms: Does not occur for not-so-old (I can't decently write "recent" :-)) versions of MingW: ssize_t was added to sys/types.h around mid-2004 Possible fix: Perhaps adding AC_CHECK_TYPE(ssize_t, int) to libcpp/configure.ac does the job, but I am not fluent enough with autoconf to be sure (and autoconf|perl does not work correctly on my machine, sorry for that). Additional comments: The most surprising part was when I started looking at it: the problem was obvious, yet the first seek of ssize_t through the compilation log got the above point (about "checking for ssize_t... no"): what would be the point to auto-check for ssize_t and then fail to provide any workaround? Later I realize that the check was implemented (a looong time ago; ChangeLog says 2000-05-27 from Zack W.) inside GCC, and it was not replicated/moved_along into the semi-independent libcpp when developped; according to the additionnal comments #12 in PR/15491 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15491#c12), the problem came in 2004, probably when the libcpp/ tree was moved. I do not know if the right fix is to include some more bloating code to libcpp/files.c (copying it from whatever survives of the "infrastructure in system.h" put in by Zack in May 2000), or rather drop the test in gcc/configure.ac. -- Summary: ssize_t used in libcpp/files.c without autoconf detection Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: antoine64leca at hotmail dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
