Re: new module 'iconv_open'

Bruno Haible <[EMAIL PROTECTED]> writes: > What do you gain by knowing this at configure time, rather than at "make" > time, a little later? To proceed with the build, you need to install gperf > anyway. In PSPP, we've been trying to display all the missing prerequisite libraries together at the

Re: missing dependency in *printf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 4/2/2007 9:34 PM: > In trying to use sprintf-posix in m4, I came across this: > > cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf > configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WO

missing dependency in *printf

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In trying to use sprintf-posix in m4, I came across this: cd .. && /bin/sh /home/eblake/m4-head/ltdl/config/missing --run autoconf configure:25505: error: possibly undefined macro: gl_FUNC_LDEXPL_WORKS If this token and others are legitimate, pl

Re: new module 'iconv_open'

John Darrington wrote: > ./configure could show a warning if gperf is not found or is too old. What do you gain by knowing this at configure time, rather than at "make" time, a little later? To proceed with the build, you need to install gperf anyway. Bruno

test-stat-time failure on FreeBSD 6

Hello James, On FreeBSD/x86 6.1, on a NFS mount, the test-stat-time test fails: $ gdb test-stat-time ... (gdb) run Program received signal SIGABRT, Aborted. 0x28127363 in kill () from /lib/libc.so.6 (gdb) where #0 0x28127363 in kill () from /lib/libc.so.6 #1 0x28127300 in raise () from /lib/lib

Re: new module 'iconv_open'

On Tue, Apr 03, 2007 at 12:43:19AM +0200, Bruno Haible wrote: Simon Josefsson wrote: > Well, at least after I installed > gperf, before that I got this error during build: > > make[2]: Entering directory `/home/jas/src/libidn/lib/gl' > gperf -m 10 iconv_open-aix.gperf

Re: EX_OK collision

Simon Josefsson wrote: > > How about (b)? It seems the simplest. > > > >> (b) Create a replacement that does > >> > >> #include > >> #undef EX_OK > >> #include > > Yes, I think so too. ... OK, after you both agreed, I commit this: 2007-04-02 Bruno Haible <[EMA

Re: EXC_I386_DIV (divide by zero)

Hello, Ryan Schmidt wrote: > Hi. I hope this is the right place to report gettext bugs. Yes, you're welcome. > On a MacBook Pro (with Intel Core 2 Duo processor) with Mac OS X > 10.4.9, a GUI dialog box containing the following error appears twice > during the configuration phase of gettext

update intdiv0.m4

Regarding integer division by 0, x86_64 behaves like i386. 2007-04-02 Bruno Haible <[EMAIL PROTECTED]> * m4/intdiv0.m4 (gt_INTDIV0): When cross-compiling, treat x86_64 like i386. --- m4/intdiv0.m4 13 Feb 2007 22:49:23 - 1.5 +++ m4/intdiv0.m4 3 Apr 2007 00:

Re: new module 'iconv_open'

Simon Josefsson wrote: > Well, at least after I installed > gperf, before that I got this error during build: > > make[2]: Entering directory `/home/jas/src/libidn/lib/gl' > gperf -m 10 iconv_open-aix.gperf > iconv_open-aix.h-t > /bin/sh: gperf: command not found > make[2]: *** [iconv_open-aix.h]

Re: new module 'iconv_open'

Eric Blake wrote: > gperf --version > GNU gperf 2.7.2 Come on! gperf 3.0.1 was released four years ago, and you are still using its seven year old predecessor? > gperf is not on the list of widely available programs, so it must not be > invoked by a normal user when compiling a tarball Right. A

Re: seekable stdin test failure on OS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ben Pfaff on 4/2/2007 12:56 PM: > Is there a version of POSIX newer than "The Open Group Base > Specifications Issue 6: IEEE Std 1003.1, 2004 Edition"? This > version doesn't say anything about the behavior of fflush for > input streams,

Re: seekable stdin test failure on OS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 4/2/2007 12:41 PM: > Ben Pfaff <[EMAIL PROTECTED]> writes: > >> ISO C89 and C99 say that fflush(stdin) yields undefined behavior, >> so I'm inclined to agree. > > It's more complicated than that, I'm afraid. > > Here's ho

Re: seekable stdin test failure on OS X

Paul Eggert <[EMAIL PROTECTED]> writes: > Ben Pfaff <[EMAIL PROTECTED]> writes: > >> ISO C89 and C99 say that fflush(stdin) yields undefined behavior, >> so I'm inclined to agree. > > Here's how I remember it; I haven't checked the actual documents. In > the late 1980s the POSIX committee decided

Re: seekable stdin test failure on OS X

Ben Pfaff <[EMAIL PROTECTED]> writes: > ISO C89 and C99 say that fflush(stdin) yields undefined behavior, > so I'm inclined to agree. It's more complicated than that, I'm afraid. Here's how I remember it; I haven't checked the actual documents. In the late 1980s the POSIX committee decided that

Re: seekable stdin test failure on OS X

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > So it seems that using fflush(stdin) is probably the wrong thing > to do altogether for a portable application. ISO C89 and C99 say that fflush(stdin) yields undefined behavior, so I'm inclined to agree. -- Ben Pfaff [EMAIL PROTECTED]

Re: seekable stdin test failure on OS X

> Even on Linux, the fflush man page doesn't mention input streams: > >http://www.die.net/doc/linux/man/man3/fflush.3.html > > So it seems that using fflush(stdin) is probably the wrong thing > to do altogether for a portable application. On the contrary, it makes it sound like we write a g

Re: seekable stdin test failure on OS X

On 2 Apr 2007, at 17:24, Paul Eggert wrote: "Gary V. Vaughan" <[EMAIL PROTECTED]> writes: At worst we need an autoconf test to see whether fflush works on stdin, but maybe all that is needed is to call fpurge when present, and fallback to fflush otherwise? For what it's worth, on Solaris it

Re: seekable stdin test failure on OS X

"Gary V. Vaughan" <[EMAIL PROTECTED]> writes: > At worst we need an autoconf test to see whether fflush works on stdin, > but maybe all that is needed is to call fpurge when present, and > fallback to fflush otherwise? For what it's worth, on Solaris it's called __fpurge and is declared in (alon

Re: new module 'iconv_open'

Eric Blake <[EMAIL PROTECTED]> writes: > Bruno Haible clisp.org> writes: > >> >> Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are >> actually usable if >> 1. one is willing to do an indirect conversion (through UTF-8) if a direct >> conversion between two encodings does

Re: new module 'iconv_open'

Bruno Haible clisp.org> writes: > > Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are > actually usable if > 1. one is willing to do an indirect conversion (through UTF-8) if a direct > conversion between two encodings doesn't exist, > 2. one maps the standardized enco

Re: source(builtin) and read(2)

Geoff Clare wrote: Ironically, it is the wording for SSIZE_MAX that is closest to being right and the others that all need to change, as the wording in the C Standard is "maximum value for an object of type ". I still think that's the *worst* wording. "Maximum value of type " is to me unam

Re: seekable stdin test failure on OS X

Hi Eric, Here is the relevant code from modules/m4.c in CVS HEAD: 508/* POSIX requires that if m4 doesn't consume all input, but stdin is 509 opened on a seekable file, that the file pointer be left at the 510 next character on exit (but places no restrictions on t

Re: seekable stdin test failure on OS X

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gary V. Vaughan on 4/2/2007 6:44 AM: > Hi Eric, Hi Gary, and adding gnulib readers, >> >> Yuck. I think this means that on your platform, fflush(stdin) is >> neglecting to reset the underlying fd position when stdin is seekable, >> whic

Re: source(builtin) and read(2)

James Youngman <[EMAIL PROTECTED]> wrote, on 31 Mar 2007: > > It seems to me that there is a certain amount of > (confusion|disagreement) among members of the austin-group-l mailing > list, who are, almost by definition, connoisseurs of standards wording > and distinguishers of fine points. > > If