Re: [Bug-tar] GNU tar 1.23 build broke in Unixware 7.1.4

[Jarkko Hietaniemi]

On Thursday-201512-03 18:25, Paul Eggert wrote:
> On 12/03/2015 05:30 AM, Jarkko Hietaniemi wrote:
> > Looks like rpl_lstat() thinks it's working with 'struct stat64'
> >
> > 5469:extern      int    rpl_lstat       (const char *name, struct
> > stat64  *buf)
> >
> > but then e.g. fstatat() is trying to use 'struct stat'.
> >
> > Using -E on lstat.c shows that e.g.
> >
> > static int
> > orig_lstat (const char *filename, struct stat64  *buf)
> > {
> >    return lstat64  (filename, buf);
> > }
>
> Tar wants struct stat64 uniformly. Plain 'struct stat' is for
> brain-damaged old progams that fall over and die if off_t is wider than
> 32 bits, and tar's not like that.
>
> How is the off_t width determined on your system?  On 32-bit GNU/Linux,
> config.h should contain a line "#define _FILE_OFFSET_BITS 64". Some
> other systems require "#define _LARGE_FILES 1" instead.

#define _FILE_OFFSET_BITS 64
/* #undef _LARGEFILE_SOURCE */ 

/* #undef _LARGE_FILES */
/* #undef off_t */ 


config.h attached.

> What does Unixware require for "struct stat" to expand to "struct 
stat64"? You can
> look in /usr/include to find out.

Looking at the fstatat.i (output of -E) it at least looks like both 
struct stat and struct stat64 do get defined.  The _FILE_OFFSET_BITS 
gets the stat64 visible (also another symbol _LARGEFILE64_SOURCE would). 
 Still trying to untangle out where/how the wrong thing gets to be 
#defined.

> I'm puzzled as to why the problem occurs for rpl_lstat but not for
> fstatat. tar-1.28/gnu/fstatat.c includes config.h first thing, so why
> don't the config.h settings cause it to use struct stat64 instead of
> struct stat? After all, the config.h settings work elsewhere.

I'm quite puzzled, too.  Maybe I should write a small test program with 
struct stat and try it with various -D settings.

> Also, looking at your log, there's one other problem that keeps popping up:
>
>     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:

#define HAVE_WCTYPE_H 1

config.h.gz
Description: GNU Zip compressed data