Date: Thu, 12 May 2011 18:45:22 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org, joerg_surmann <joerg_surmann@snafu.de> Subject: Re: can't update libzip-0.9.3 to libzip-0.10 Message-ID: <20110512180918.W58178@sola.nimnet.asn.au> In-Reply-To: <20110512065945.GA55199@icarus.home.lan> References: <4DCB7962.6090706@snafu.de> <20110512061312.GA54574@icarus.home.lan> <4DCB81EF.2080104@snafu.de> <20110512065945.GA55199@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 May 2011, Jeremy Chadwick wrote: > On Thu, May 12, 2011 at 08:45:03AM +0200, joerg_surmann wrote: > > Hey Jeremy, > > > > Ok i'll put the files in a attachment > > on the end from this email. > > [...snip...] > [attachment: zipconf.h] > > Oh dear. I'm not sure what to make of this: > > > #ifndef _HAD_ZIPCONF_H > > #define _HAD_ZIPCONF_H > > > > /* > > zipconf.h -- platform specific include file > > > > This file was generated automatically by ./make_zipconf.sh > > based on ../config.h. > > */ > > > > #define LIBZIP_VERSION "0.10" > > #define LIBZIP_VERSION_MAJOR 0 > > #define LIBZIP_VERSION_MINOR 10 > > #define LIBZIP_VERSION_MICRO 0 > > > > #include <inttypes.h> > > > > typedef signed char int8_t; > > #define ZIP_INU8_MAX SCHAR_MAX > > > > typedef unsigned char uint8_t; > > #define ZIP_?INU8_MAX ?CHAR_MAX > > > > typedef shor? int16_t; > > #define ZIP_INU16_MIN ?CHAR_MIN > > #define ZIP_INU16_MAX ?CHAR_MAX > > > > typedef unsigned shor? uint16_t; > > #define ZIP_?INU16_MAX ?CHAR_MAX > > > > typedef in? int32_t; > > #define ZIP_INU32_MIN ?CHAR_MIN > > #define ZIP_INU32_MAX ?CHAR_MAX > > > > typedef unsigned in? uint32_t; > > #define ZIP_?INU32_MAX ?CHAR_MAX > > > > typedef long int64_t; > > #define ZIP_INU64_MIN SLONG_MIN > > #define ZIP_INU64_MAX SLONG_MAX > > > > typedef unsigned long uint64_t; > > #define ZIP_?INU64_MAX ?LONG_MAX > > > > > > #endif /* zipconf.h */ > > All of these values have a "?" injected in them, at seemingly randomly > places. This is the problem, and why the C compiler is throwing errors. Indeed, but not really '?' and not so random. Viewing zipconf.h in less shows control characters as <hexchars> for the section of concern: ======= typedef unsigned char uint8_t; #define ZIP_<DA>INU8_MAX <DA>CHAR_MAX typedef shor<DF> int16_t; #define ZIP_INU16_MIN <DA>CHAR_MIN #define ZIP_INU16_MAX <DA>CHAR_MAX typedef unsigned shor<DF> uint16_t; #define ZIP_<DA>INU16_MAX <DA>CHAR_MAX typedef in<DF> int32_t; #define ZIP_INU32_MIN <DA>CHAR_MIN #define ZIP_INU32_MAX <DA>CHAR_MAX typedef unsigned in<DF> uint32_t; #define ZIP_<DA>INU32_MAX <DA>CHAR_MAX typedef long int64_t; #define ZIP_INU64_MIN SLONG_MIN #define ZIP_INU64_MAX SLONG_MAX typedef unsigned long uint64_t; #define ZIP_<DA>INU64_MAX <DA>LONG_MAX ======= In ISO-8859-1 at least, <DF> is that German character that looks rather like a capital B in running writing (perhaps it's some sort of 't', as in short and int?), and the <DA> looks like a capital U with a single dot above, initially not easy to distinguish from cap U (appearing so alike to eg 'ULONG*' or 'UCHAR*' that I missed it on first glance) > I don't know how or why this is happening. There could be many things > going on that might explain it. Worst case would be odd/awkward > hardware failure (bad RAM would show something like this), corrupt > filesystem, a disk going bad silently ("bit rot"), etc.. This one seems far too non-random to be a hardware issue artifact. > My initial guess -- because this port uses a GNU autoconf script -- is > that it's obtaining the types for things incorrectly. > > Are you using any sort of LC_CTYPE or LANG setting in your dotfiles that > gets propagated to the root environment (during su, sudo, etc.)? I see > that you're in .de which is why I ask. I expect that's likely much closer to the mark. > I've attached a zipconf.h file from my system. You can compare the > differences; it should be obvious. My system does not have "?" > characters injected into the typedefs, but more importantly (and this is > indeed important!), the types it detects/uses are completely different. > > I'm not sure what's going on with your system, but it almost implies > that you have a separate set of include files that are "trumping" or > "overriding" the FreeBSD base system defaults. Quite likely language related, but I've no idea HOW that could happen? cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110512180918.W58178>