Tcl Source Code

View Ticket
Login
Ticket UUID: 874058
Title: wrong Tcl_StatBuf type with 64 HP Ansi C
Type: Bug Version: obsolete: 8.5a0
Submitter: rwurth Created on: 2004-01-09 21:19:18
Subsystem: 53. Configuration and Build Tools Assigned To: hobbs
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2004-07-20 03:16:19
Resolution: Fixed Closed By: hobbs
    Closed on: 2004-07-19 20:16:18
Description:
When trying to build tcl on an HP system using HP's
optional ANSI C compiler (the default compiler that
comes with the system supports almost no features and
is suitable only for recompiling kernel table
declarations), many instances of the following error
pairs occur for files unix/tclUnixFile.c and
unix/tclUnixFCmd.c:  

warning 604: Pointers are not assignment-compatible.
warning 563: Argument #2 is not the correct type.


In these files each calls to TclOSstat or TclOSlstat
generates this pair of errors.  

Examining the results after pre-processing, but before
compiling reveals that the calls to Tcl_OSstat and
Tcl_OSlstat are being mapped to native calls stat and
lstat, respectively.  

The function prototypes for both show a second argument
of type (stat *).  The calling code passes an argument
of type (Tcl_StatBuf *), which is a typedef for (struct
stat64 *).  There are 2 subtle differences between the
structures.  First, member st_size is off_t (a typedef
for long), in stat, but off64_t, a typedef for
int64_t,. which is a typedef for long.  This is
probably not a problem because the names are the same
and the base types are the same.  Secondly, where stat
has member blckcnt_t, also of type off_t, stat64 has
member blckcnt64_t, of type int64_t.  The base class is
the same for both, but the names are different.  

OS details (uname -a):  HP-UX urkel B.11.00 U 9000/800
1552710528 unlimited-user license

Compiler lines:  

/usr/bin/cc -c -O -DTCL_DBGX=  +z -I./../generic -I.
+DA2.0W -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\"
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-DTCL_CFGVAL_ENCODING=\"iso8859-1\"
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
-DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1
-DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_MODEM_H=1 -DUSE_TERMIOS=1
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_TZNAME=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1
-DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1
-DHAVE_ST_BLKSIZE=1 -DNO_UNION_WAIT=1 -DNO_GETTOD=1
-DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1
-D_XOPEN_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1
-DTCL_CFG_DO64BIT=1 -DTCL_CFG_OPTIMIZED=1
-DTCL_CFG_DEBUG=1 -DHAVE_SYS_IOCTL_H=1        
-DTCL_SHLIB_EXT=\".sl\" ./../unix/tclUnixFCmd.c


/usr/bin/cc -c -O -DTCL_DBGX=  +z -I./../generic -I.
+DA2.0W -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\"
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
-DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-DTCL_CFGVAL_ENCODING=\"iso8859-1\"
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
-DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
-DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1
-DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1
-DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1
-DHAVE_SYS_MODEM_H=1 -DUSE_TERMIOS=1
-DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_TZNAME=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1
-DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1
-DHAVE_ST_BLKSIZE=1 -DNO_UNION_WAIT=1 -DNO_GETTOD=1
-DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1
-D_XOPEN_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1
-DTCL_CFG_DO64BIT=1 -DTCL_CFG_OPTIMIZED=1
-DTCL_CFG_DEBUG=1 -DHAVE_SYS_IOCTL_H=1        
-DTCL_SHLIB_EXT=\".sl\" ./../unix/tclUnixFile.c


Config command line:  

MAKE=gmake CC=/usr/bin/cc ./configure \
  --enable-shared \
  --enable-64bit \
  --prefix=/usr/local/tcl-X/tcl8.5 \
  --exec-prefix=/usr/local/tcl-X/tcl8.5

config.log attached.
User Comments: hobbs added on 2004-07-20 03:16:19:

File Added - 94484: reorder-config-tk84.patch

hobbs added on 2004-07-20 03:16:18:
Logged In: YES 
user_id=72656

added patch applied for core-8-4-branch (Tk) for 8.4.7.

This has now been applied to all active Tcl/Tk branches.

hobbs added on 2004-07-20 03:15:00:

File Added - 94483: reorder-config-tcl84.patch

hobbs added on 2004-07-20 03:14:59:
Logged In: YES 
user_id=72656

added patch applied for core-8-4-branch for 8.4.7.

hobbs added on 2004-05-27 05:56:18:

File Added - 88570: reorder-config.patch

Logged In: YES 
user_id=72656

attached is a patch against cvs head that reorders configure
to do the CFLAGS changes *before* the 64bit fs checks.  It
corrects the above condition, but needs wider testing.

The patch requires regenerating configure, as including that
part makes the patch too large.

hobbs added on 2004-05-27 05:53:36:
Logged In: YES 
user_id=72656

Attached is a patch to the tcl cvs head that has been
commited for testing.  It reorders configure to do the
CFLAGS checks and additions (notably for --enable-64bit)
before the TCL_64BIT_FLAGS  and EARLY_FLAGS checks.  It
places them after AC_PROG_CC still.

hobbs added on 2004-05-27 00:14:40:
Logged In: YES 
user_id=72656

The problem is that you need to set the appropriate
CFLAGS=+DD64 before you call ./configure.  This exposes a
bigger problem with Tcl's current configure stuff - it's
broken at a very base level for many compile variants
(64-bit and cross-compilation most affected).

dkf added on 2004-01-12 16:57:33:
Logged In: YES 
user_id=79902

And I'm not qualified to comment on HP-UX (I've never used
it.)  However, in general I can say that what seems to be
happening is that we are determining that we need to use a
64-bit stat buffer (for extension backward-compatability
reasons, this means we use 'struct stat64' instead of doing
the #defs that enlarge the size of the 'struct stat') but
are deciding that we should use the other names for the
'stat' and 'lstat' calls.  This Is Not Good.  This is
particularly Not Good as the same #def should enable the use
of matching values (i.e. they are both guarded by #ifdef
HAVE_STRUCT_STAT64.)  :^(

Assigning to Jeff because I don't know where to begin
figuring out what is wrong.  Send it back to me once there
is an explanation of what the real failure is and I'll try
to fix...

vincentdarley added on 2004-01-10 21:29:16:
Logged In: YES 
user_id=32170

I'm not qualified to comment on a 64-bit issue...

rwurth added on 2004-01-10 04:19:18:

File Added - 72875: config.log

Attachments: