Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69
Date: 2013-12-29 18:05:29
Message-ID: 14711.1388340329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

I wrote:
> Perhaps though we should override Autoconf's setting of
> _DARWIN_USE_64_BIT_INODE, if we can do that easily? It's clearly
> not nearly as problem-free on 10.5 as the Autoconf boys believe,
> and it's already enabled by default on the release series where it
> does work.

I looked into this and found that _DARWIN_USE_64_BIT_INODE is being turned
on by AC_SYS_LARGEFILE. Quite aside from the wisdom of doing this at all,
it's got nothing to do with the advertised purpose of that macro: the
width of inode_t would affect how many files you can put on one
filesystem, not how large the individual files are. I don't think that is
something that we need to concern ourselves with enabling when it's not
the platform default. And just to add insult to injury, the
implementation technique is such that the #define gets put into
pg_config.h unconditionally, even if AC_SYS_LARGEFILE isn't executed by
the configure script!

So IMO this is brain-dead in at least three different ways, and I've
pushed a patch to revert it.

We still need to address the other issues enumerated in my previous
message, but this should be enough to get buildfarm member locust
happy again.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Kevin Grittner 2013-12-29 21:24:27 pgsql: Don't attempt to limit target database for pg_restore.
Previous Message Tom Lane 2013-12-29 17:58:17 pgsql: Undo autoconf 2.69's attempt to #define _DARWIN_USE_64_BIT_INODE

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Konoplev 2013-12-29 21:22:20 Re: Polymorphic function calls
Previous Message Tom Lane 2013-12-29 17:38:00 Re: [BUG FIX] Version number expressed in octal form by mistake