On Tue, Jul 31, 2007 at 11:02:53PM -0400, Austin wrote:
> Chris Frey wrote:
> >On Mon, Jul 23, 2007 at 10:39:44AM -0400, Austin wrote:
> >>Hi everyone.  The current cvs is not building on Mandriva linux.
> >
> >Thanks for the bug report!
> >
> >What platform are you building on?  64 bit? 32 bit?
> 
> This error was from 32 bit, but it will also have to compile on 64 bit 
> to be included with Mandriva.
> 
> >Also, could you find the libtar.h on your system and send it to me?
> >I'm curious why file handles have suddenly changed from int to long int.
> 
> Attached.
> 
> [EMAIL PROTECTED] /]$ rpm -q libtar-devel
> libtar-devel-1.2.11-6mdv2007.0
> 
> >Also, what prototype is documented in "man 2 read" on your system?  I have:
> >     ssize_t read(int fd, void *buf, size_t count);
> 
> Not sure.  $ man 2 read
> does not return anything.

Your other email included the manpage in the pastebin:  (Thanks!)

       ssize_t read(int fd, void *buf, size_t count);


> >>tarfile-ops-nt.cc:107: error: invalid conversion from 'int (*)(int)' to 
> >>'int (*)(long int)'
> >>tarfile-ops-nt.cc:107: error: invalid conversion from 'ssize_t (*)(int, 
> >>void*, size_t)' to 'ssize_t (*)(long int, void*, size_t)'
> >>tarfile-ops-nt.cc:107: error: invalid conversion from 'ssize_t (*)(int, 
> >>const void*, size_t)' to 'ssize_t (*)(long int, const void*, size_t)'


I've taken a closer look, and this is a bug in Mandriva's version of
libtar.  It is from the following patch for 64-bit fixes:

-----------------------------------------------------------------------------
2005-01-21  Gwenole Beauchesne  <[EMAIL PROTECTED]>

        * 64-bit fixes causing a slight API change. This is necessary if you
        want .tar.gz support (as the libtar sample application). Note that it
        already worked as is on x86_64 but the code was not fully 64-bit clean
        and relied on behaviour that turned to work there.

--- libtar-1.2.11/lib/libtar.h.64bit-fixes      2003-01-07 02:40:59.000000000 +0
100
+++ libtar-1.2.11/lib/libtar.h  2005-07-21 17:07:25.000000000 +0200
@@ -62,10 +62,10 @@ struct tar_header
 
 /***** handle.c ************************************************************/
 
-typedef int (*openfunc_t)(const char *, int, ...);
-typedef int (*closefunc_t)(int);
-typedef ssize_t (*readfunc_t)(int, void *, size_t);
-typedef ssize_t (*writefunc_t)(int, const void *, size_t);
+typedef long (*openfunc_t)(const char *, int, ...);
+typedef int (*closefunc_t)(long);
+typedef ssize_t (*readfunc_t)(long, void *, size_t);
+typedef ssize_t (*writefunc_t)(long, const void *, size_t);

-----------------------------------------------------------------------------

This is to fix a 64-bit pointer problem in the libtar example, where
it casts a void pointer (gzFile) to an int.

Here's a snippet from libtar's gzip example:

-----------------------------------------------------------------------------
int
gzopen_frontend(char *pathname, int oflags, int mode)
{
        char *gzoflags;
        gzFile gzf;
...
        return (int)gzf;
}
-----------------------------------------------------------------------------

gzFile is defined in the zlib headers as a void pointer.

It is incorrect to change the libtar API for this bug, since the libtar
API matches the system's open/close/read/write C API, and C has not
changed to long file handles, as noted in the man page above.

The real bug is in the libtar example code.

I've CC'd Gwenole Beauchesne, and hopefully Mandriva can fix this
in their next release.

Thanks for the report,
- Chris


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel

Reply via email to