From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | marti(at)juffo(dot)org |
Subject: | Why buildfarm member anchovy is failing on 8.2 and 8.3 branches |
Date: | 2011-08-28 20:15:33 |
Message-ID: | 3579.1314562533@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I spent a bit of time looking into $SUBJECT. The cause of the failure
is that configure mistakenly decides that setproctitle and some other
functions are available, when they aren't; this eventually leads to link
failures of course.
Now 8.2 and 8.3 use autoconf 2.59. 8.4 and up, which do not exhibit
this failure, use autoconf 2.61 or later. Sure enough, there is a
difference in the test program generated by the more recent autoconfs:
they actually try to call the function, where the previous ones do
something weird involving a function pointer comparison. I dug in the
autoconf change log and found this:
2005-10-19 Paul Eggert <eggert(at)cs(dot)ucla(dot)edu>
(AC_LANG_FUNC_LINK_TRY(C)): Call the function rather than simply
comparing its address. Intel's interprocedural optimization was
outsmarting the old heuristic. Problem reported by
Mikulas Patocka.
Since anchovy is using the "gold" linker at -O3, it's not exactly
surprising that it might be carrying out aggressive interprocedural
optimizations that we're not seeing used on other platforms.
The bottom line seems to be that autoconf 2.59 is seriously broken on
recent toolchains. Should we try to do something about that, like
migrate the 8.2 and 8.3 releases to a newer autoconf? 8.2 is close
enough to EOL that I don't mind answering "no" for it, but maybe we
should do that in 8.3.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-08-28 21:40:37 | Re: Why buildfarm member anchovy is failing on 8.2 and 8.3 branches |
Previous Message | Kohei KaiGai | 2011-08-28 18:32:30 | [v9.2] Object access hooks with arguments support (v1) |