Thread: Compiling HEAD with -Werror int 64-bit mode
Hi
HEAD fails to compile in 64-bit mode on Mac OS X 10.6 with gcc 4.2 and
-Werror.
What happens is that INT64_FORMAT gets defined as "%ld" (which is
correct - "long" and "unsigned long" are 64 bits wide on x86_64), but
the check for a working 64-bit int fails, causing INT64_IS_BUSTED to get
defined and int64 becoming actually a 32-bit type. This is turn causes
warnings when these pseudo int64s are passed to printf with format
specified INT64_FORMAT, which get turned to errors by -Werror.
configure fails to recognize "long" as a working 64-bit type because the
does_int64_work configure test produces warning due to a missing return
value declaration for main() and a missing prototype for
does_int64_work(). (Aain, those warning are turned into errors by -Werror).
I use the following envvar settings (when running ./configure) to force
64-bit mode and -Werror
CC=gcc-4.2 CFLAGS="-arch x86_64 -Werror" LDFLAGS="-arch x86_64"
The following patch fixed the problem for me - though I didn't yet try
it on any other platform that Mac OS X 10.6 with gcc 4.2 and in 64-bit mode.
----------------------------------------------------------------------
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 9ac2c30..c6bd523 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -35,7 +35,7 @@ AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar], ac_int64 a = 20000001; ac_int64 b = 40000005;
-int does_int64_work()
+static int does_int64_work() { ac_int64 c,d;
@@ -49,8 +49,8 @@ int does_int64_work() return 0; return 1; }
-main() {
- exit(! does_int64_work());
+int main() {
+ return(! does_int64_work()); }], [Ac_cachevar=yes], [Ac_cachevar=no],
----------------------------------------------------------------------
best regards,
Florian Pflug
"Florian G. Pflug" <fgp@phlo.org> writes:
> configure fails to recognize "long" as a working 64-bit type because the
> does_int64_work configure test produces warning due to a missing return
> value declaration for main() and a missing prototype for
> does_int64_work(). (Aain, those warning are turned into errors by -Werror).
autoconf's test programs tend to be sufficiently sloppy that I would
expect -Werror to break a whole lot of things, not just this.
We can possibly neaten up the particular test case but there are many
tests whose expansion we don't have much control over.
regards, tom lane
On 15.12.09 16:02 , Tom Lane wrote: > "Florian G. Pflug"<fgp@phlo.org> writes: >> configure fails to recognize "long" as a working 64-bit type >> because the does_int64_work configure test produces warning due to >> a missing return value declaration for main() and a missing >> prototype for does_int64_work(). (Aain, those warning are turned >> into errors by -Werror). > > autoconf's test programs tend to be sufficiently sloppy that I would > expect -Werror to break a whole lot of things, not just this. We can > possibly neaten up the particular test case but there are many tests > whose expansion we don't have much control over. Yeah, I expected all hell to break loose - only to be pleasantly surprised by this being the only issue I encountered. So I figured fixing this might be worthwhile - even if this surely does not fix -Werror builds on all platforms and/or compilers. Alternatively - is there a way to use -Werror only for building the actual sources, not the configure tests? I didn't find one, but my autoconf-fu is pretty limited... best regards, Florian Pflug
On 12/15/09, Florian G. Pflug <fgp@phlo.org> wrote: > On 15.12.09 16:02 , Tom Lane wrote: > > > "Florian G. Pflug"<fgp@phlo.org> writes: > > > > > configure fails to recognize "long" as a working 64-bit type > > > because the does_int64_work configure test produces warning due to > > > a missing return value declaration for main() and a missing > > > prototype for does_int64_work(). (Aain, those warning are turned > > > into errors by -Werror). > > > > > > > autoconf's test programs tend to be sufficiently sloppy that I would > > expect -Werror to break a whole lot of things, not just this. We can > > possibly neaten up the particular test case but there are many tests > > whose expansion we don't have much control over. > > > > Yeah, I expected all hell to break loose - only to be pleasantly > surprised by this being the only issue I encountered. So I figured > fixing this might be worthwhile - even if this surely does not fix > -Werror builds on all platforms and/or compilers. > > Alternatively - is there a way to use -Werror only for building the > actual sources, not the configure tests? I didn't find one, but my > autoconf-fu is pretty limited... make CC="gcc -Werror"? to make it easier to use we could add --enable-werror switch to configure, which adds the -Werror as a last step in configure, or maybe even in Makefile, so the autoconf tests stay working. -- marko
On tis, 2009-12-15 at 16:15 +0100, Florian G. Pflug wrote: > Alternatively - is there a way to use -Werror only for building the > actual sources, not the configure tests? I didn't find one, but my > autoconf-fu is pretty limited... I always build with pgmake='make COPT="-Werror -Wno-inline"' (The -Wno-inline is obsolete in more recent version.) I have also tried in the past to pass -Werror through configure, but that caused too many problems.
Peter Eisentraut <peter_e@gmx.net> writes:
> I have also tried in the past to pass -Werror through configure, but
> that caused too many problems.
Is it your opinion that we shouldn't bother fixing this particular
test? I was on the fence about it myself. I don't want to promise
that configuring with -Werror will work, now or in the future; but
making this one test safe doesn't seem too onerous.
regards, tom lane
On 12/15/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I have also tried in the past to pass -Werror through configure, but > > that caused too many problems. > > Is it your opinion that we shouldn't bother fixing this particular > test? I was on the fence about it myself. I don't want to promise > that configuring with -Werror will work, now or in the future; but > making this one test safe doesn't seem too onerous. It's better to fail with certainty, than toggle randomly some features on/off... Unless autoconf guys promise that their macros are meant to work with -Werror, it seems safer to fail. Plus there are our own macros. How about explicit switch to turn -Werror on, safely? -- marko
On tis, 2009-12-15 at 16:22 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I have also tried in the past to pass -Werror through configure, but > > that caused too many problems. > > Is it your opinion that we shouldn't bother fixing this particular > test? I was on the fence about it myself. I don't want to promise > that configuring with -Werror will work, now or in the future; but > making this one test safe doesn't seem too onerous. I don't mind making this one test more correct, although I haven't fully verified the particular details of the proposed change. But after checking again now, passing -Werror through configure in a sane way appears impossible and futile. Pretty much all the compile-and-link tests for functions, e.g., cbrt, memmove, snprintf, (as opposed to the usual link-only tests) fail because of prototype mismatches, because configure just declares functions char memmove (); independent of the correct call signature. There are a few other problems as well. You could perhaps get away with it if you don't pass any other warning options into configure, but then what warnings is it supposed to error about? So to summarize, this is just a bad idea. Creating a less obscure way to use -Werror might be worthwhile, though.
Peter Eisentraut <peter_e@gmx.net> writes:
> So to summarize, this is just a bad idea. Creating a less obscure way
> to use -Werror might be worthwhile, though.
I suppose we could add "--with-Werror" but it seems pretty specialized
to me. A more appropriate solution would allow the user to provide
flags that get added to CFLAGS only after we do all the configure tests
(implying that it's on the user's head that these flags are right and
don't break anything, but then again that's pretty much true of up-front
CFLAGS too). And that basically describes COPTS ... the only thing
lacking is documentation.
regards, tom lane
On 15.12.09 23:38 , Tom Lane wrote: > Peter Eisentraut<peter_e@gmx.net> writes: >> So to summarize, this is just a bad idea. Creating a less obscure >> way to use -Werror might be worthwhile, though. > > I suppose we could add "--with-Werror" but it seems pretty > specialized to me. A more appropriate solution would allow the user > to provide flags that get added to CFLAGS only after we do all the > configure tests (implying that it's on the user's head that these > flags are right and don't break anything, but then again that's > pretty much true of up-front CFLAGS too). And that basically > describes COPTS ... the only thing lacking is documentation. For what it's worth, I agree. Though we might want to arrange for configure to store the value of COPT somewhere so that COPT="-Werror" ./configure make works which it currently doesn't seem to. best regards, Florian Pflug