On 12/04/2015 05:27 AM, Jarkko Hietaniemi wrote:
Looking at the fstatat.i (output of -E) it at least looks like both
struct stat and struct stat64 do get defined.
Yes, it's common for this sort of thing to occur regardless of whether
_FILE_OFFSET_BITS is defined. What commonly happens is for a standard
include file to have '#define stat stat64' at a strategic moment, if
_FILE_OFFSET_BITS is 64, so that the program accesses the stat64
function and uses the struct stat64 even though the source code says
only 'stat' and 'struct stat' (and even though part of the gcc -E output
also says plain 'struct stat' and 'stat'). If that is what Unixware
does, you need to find out where it's done, and why it's working for
some occurrences of 'stat' in user code but not for other occurrences.
There are other ways to implement it, e.g., symbol aliases; depends on
what Unixware does.
CC exclude.o
In file included from exclude.c:36:
wctype.h:634: warning: `iswblank' redefined
/usr/local/lib/gcc-lib/i686-UnixWare7.0.1-sysv5/2.95.2/include/wctype.h:137:
warning: this is the location of the previous definition
What's up with that? It should get fixed too. What's the preprocessor
output for this one?
It really looks like first the (ancient!) gcc wctype.h gets included,
and defines iswblank(), and then the "wctype.h" (in gnu/) gets
included, and redef of iswblank() is attempted. Now, I guess the
question is why are both included... config.h does say:
Presumably 'configure' decided that the GCC-supplied wctype.h wasn't
adequate, and decided to supply the gnulib wctype.h, which should
include the GCC-supplied wctype.h and then make some fixes and
additions. Presumably 'configure' also decided that the GCC-supplied
iswblank wasn't up to snuff, and decided to replace it. You need to
figure out whether (a) 'configure' was correct to replace GCC's wctype.h
and/or iswblank (it probably was, but it's worth checking), and (b) why
the replacement in gnu/wctype.h didn't work.