bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU M4 1.4.8b released (beta release)


From: Matthew Woehlke
Subject: Re: GNU M4 1.4.8b released (beta release)
Date: Thu, 01 Mar 2007 10:16:47 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20061206 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0

Eric Blake wrote:
According to Matthew Woehlke on 2/28/2007 5:46 PM:
Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
thing, just because 'long long' exists. 16 errors trying to build printf.c.

That's because printf.c is part of gnulib, and both coreutils and m4 use
the same source file.  Whatever you do to fix it for one package will fix
it for the other; and as Bruno suggested, if compiling with CFLAGS=-O
fixes it (by detecting the brokenness of your compiler's long long), then
it probably is not worth much further effort in gnulib to work around it.

Well... aside from the fact that I forgot that (it's been quite a while), I still think that if printf.c is going to *assume* unsigned if long long exists, then config.h really ought to make this safe, say by having something like this in config.h.in:

#if defined(HAVE_LONG_LONG_INT) && !defined(HAVE_UNSIGNED_LONG_LONG_INT)
# undef HAVE_LONG_LONG_INT
#endif

...or at least in printf.c! This way things would work without having to "know" to specify special build flags.

--
Matthew
Ngx iqct zgg dxei zodt gf ngxk iqfrl.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]