Re: initdb ignoring options due to bash environment on OS X

I have solved my problem after chasing down some library trivia. It's
the fault of my own shell script, but the cause/effect was surprising to
me. I'll go through some troubleshooting library flow on OS X
documentation below since this was new to me and I wrote down notes.
Maybe this will be useful for someone else. The sole upside of this
mess is that I'm almost done with having a OS X based stack/process I
can recommend for reviewers.

My peg development wrapper script defines a function named initdb, and I
was sourcing that in. That's what broke initdb the binary. I think
this was specific to initdb because of how the hand-off is done inside
src/bin/initdb/initdb.c to find "postgres" based on the path to initdb's
argv[0]. I saw that was calling something in /bin/sh on several
operations, like this:

fixing permissions on existing directory
/Users/gsmith/pgwork/data/latest ... ok
creating subdirectories ... ok
dyld: loaded: /bin/sh
dyld: loaded: /usr/lib/libncurses.5.4.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib

[Details on getting that output also below] I'm not exactly sure why
this problem doesn't pop on Linux where I use peg all the time. Is it
because the involved shell is /bin/sh on the Mac? Is it due to linker
implementation differences? System library differences? That level of
detail doesn't seem too important to PostgreSQL development, so I didn't
chase this down to the exactly underlying difference.

Tom started me down the right path with:

On 2/26/13 7:03 PM, Tom Lane wrote:
> One of the places where it works as expected for
> me is my 10.7.5 laptop. So there's something weird about some library
> you're using. What's getting linked into initdb ("otool -L" should
> answer that) and where'd you get it from?

$ otool -L `which initdb`
/Users/gsmith/pgwork/inst/latest/bin/initdb:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 159.1.0)

Far as I know that's the OS provided version of that file. But half the
binaries on the system link to that, i.e.:

$ otool -L /bin/bash
/bin/bash:
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 159.0.0)

Note how the Mac is linking to two versions at once with the same file
name here. It doesn't use a symlink for that like I'm used to on Linux.
Also, libSystem.B.dylib is a dynamic library (.dy lib) that can pull a
lot more things in. It doesn't seem very useful on its own to know it's
being linked in.

If you want to trace all the dynamic libraries that are pulled in by
something you run from an OS X command line, set this:

$ export DYLD_PRINT_LIBRARIES="yes"

There's more of those options described here, if that's not enough:
https://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/LoggingDynamicLoaderEvents.html#//apple_ref/doc/uid/TP40002077-SW1

You also can override where the system libraries come from, similarly to
LD_LIBRARY_PATH, like this:

export DYLD_LIBRARY_PATH=/Users/gsmith/temp/

I think that only "took" usefully when I started another bash after
setting it.

Once that's done, now you get a useful list of all the libraries pulled in:

$ initdb --version
dyld: loaded: /Users/gsmith/pgwork/inst/latest/bin/initdb
dyld: loaded: /Users/gsmith/temp//libSystem.B.dylib
dyld: loaded: /usr/lib/system/libcache.dylib
dyld: loaded: /usr/lib/system/libcommonCrypto.dylib
dyld: loaded: /usr/lib/system/libcompiler_rt.dylib
dyld: loaded: /usr/lib/system/libcopyfile.dylib
dyld: loaded: /usr/lib/system/libdispatch.dylib
dyld: loaded: /usr/lib/system/libdnsinfo.dylib
dyld: loaded: /usr/lib/system/libdyld.dylib
dyld: loaded: /usr/lib/system/libkeymgr.dylib
dyld: loaded: /usr/lib/system/liblaunch.dylib
dyld: loaded: /usr/lib/system/libmacho.dylib
dyld: loaded: /usr/lib/system/libmathCommon.A.dylib
dyld: loaded: /usr/lib/system/libquarantine.dylib
dyld: loaded: /usr/lib/system/libremovefile.dylib
dyld: loaded: /usr/lib/system/libsystem_blocks.dylib
dyld: loaded: /usr/lib/system/libsystem_c.dylib
dyld: loaded: /usr/lib/system/libsystem_dnssd.dylib
dyld: loaded: /usr/lib/system/libsystem_info.dylib
dyld: loaded: /usr/lib/system/libsystem_kernel.dylib
dyld: loaded: /usr/lib/system/libsystem_network.dylib
dyld: loaded: /usr/lib/system/libsystem_notify.dylib
dyld: loaded: /usr/lib/system/libsystem_sandbox.dylib
dyld: loaded: /usr/lib/system/libunc.dylib
dyld: loaded: /usr/lib/system/libunwind.dylib
dyld: loaded: /usr/lib/system/libxpc.dylib
initdb (PostgreSQL) 9.3devel

The clue for my problem was that after all of that, the one Mac I could
make work here included these lines next:

dyld: loaded: /bin/sh
dyld: loaded: /usr/lib/libncurses.5.4.dylib
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/system/libcache.dylib ...

Making me think about the /bin/sh environment. Looking into the diff
from the working/not working output of "set > env.txt" figured out what
was going on.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com