On 2013-10-28 12:39:03 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-10-28 12:22:56 -0400, Tom Lane wrote:
> >> What I find curious is that I can't
> >> reproduce this problem on an OS X Mavericks machine here. You must
> >> be using some nondefault compiler switches --- care to tell us what?
>
> > Did you maybe compile using gcc or at least the gcc compatible frontend
> > instead of clang?
>
> Well, I have
>
> CC = gcc
>
> which is what configure will pick by default, but I see
>
> $ gcc -v
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
> Target: x86_64-apple-darwin13.0.0
> Thread model: posix
>
> so it's some variant of LLVM/clang. In any case, Matthias claimed it
> didn't make a difference which compiler he picked, and I'm pushing
> back on that assertion.
A quick search reveals that we're not the only ones suffering from this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55696
http://lists.gnu.org/archive/html/bug-bash/2013-07/msg00011.html
There's a reference around to the code in question:
http://www.opensource.apple.com/source/Libc/Libc-997.1.1/secure/strcpy_chk.c
And it seems to be enabled by:
#if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
/* Security checking functions. */
#include <secure/_string.h>
#endif
in
http://www.opensource.apple.com/source/Libc/Libc-997.1.1/include/string.h
So, if I understand it correctly, this only happens if _FORTIFY_SOURCE
is enabled. Not sure what does that on Matthias but not your machine.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services