Re: initdb ignoring options due to bash environment on OS X - Mailing list pgsql-hackers

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
(.dylib) 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com