Re: 64bit initdb failure on macOS 10.11 and 10.12

Tom Lane writes:
> rjhb(at)bb-c(dot)de (Rainer J.H. Brandt) writes:
> > This 32/64 business isn't the problem, though.
>
> > I've found out that everything works if I type the configure/make commands
> > in my shell (which isn't what I said before, sorry about that), but stops
> > working if I put them into a Perl script (which is how I automate things
> > across OSes).
>
> Ooooh, that's interesting ...
>
> > The weird thing is that the commands are absolutely the same,
> > and environment is the same, too.
>
> I bet not. We've seen problems with macOS unexpectedly deciding to
> filter away inherited environment variables in some situations.
> It might be useful to put "env >somefile" into the PG makefile and
> compare results between the two ways of invoking it.

Between the configure and make steps, I put it into the top level
GNUmakefile. Here's the diff:

18c18
< PWD=/private/tmp/buildbot.9365/postgresql-9.6.3
---
> PWD=/tmp/w/postgresql-9.6.3
21c21
< SHLVL=3
---
> SHLVL=2

This subshell level isn't relevant, or is it?
Here's the full output of the manual version:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.tMcsjxst4H/Render
DISPLAY=/private/tmp/com.apple.launchd.EahVZI82Sz/org.macosforge.xquartz:0
EDITOR=emacsclient
GROUP=people
HOME=/Users/rjhb
HOST=hawk.local
HOSTTYPE=unknown
LANG=en_US.UTF-8
LOGNAME=rjhb
MACHTYPE=x86_64
MAKEFLAGS=
MAKELEVEL=1
MANPATH=/usr/share/man:/Users/rjhb/doc/man:/opt/local/share/man
MFLAGS=
MYDISPLAY=/private/tmp/com.apple.launchd.EahVZI82Sz/org.macosforge.xquartz:0
OSTYPE=darwin
PATH=/usr/bin:/usr/sbin:/bin:/sbin
PWD=/tmp/w/postgresql-9.6.3
SECURITYSESSIONID=186a6
SHELL=/bin/tcsh
SHLVL=2
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.yAcr2eFkb9/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=388.1.1
TERM_SESSION_ID=3BEAA846-F8B4-46AC-9CB6-17ADC709E34F
TMPDIR=/var/folders/75/60nrw1lx53b5jwl1dz7g5v_40000z9/T/
USER=rjhb
VENDOR=apple
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
_=/usr/bin/env
__CF_USER_TEXT_ENCODING=0x3E9:0x0:0x0

Regards, Rainer