Thread: initdb ignoring options?
Here's a happy initdb on 9.1 providing help: $ psql --version psql (PostgreSQL) 9.1.8 $ /usr/pgsql-9.1/bin/initdb --help initdb initializes a PostgreSQL database cluster. Usage: initdb [OPTION]... [DATADIR] ... Here's what I get on the latest repo: $ psql --version psql (PostgreSQL) 9.3devel $ initdb --help The files belonging to this database system will be owned by user "gsmith". This user must also own the server process. The database cluster will be initialized with locale "en_US.UTF-8" ... initdb --version does the same thing for me: ignores the command line and just goes onward to create a new cluster. I checked a random, not current 9.2 install and saw the same issue existed on that version too: $ psql --version psql (PostgreSQL) 9.2.1 $ initdb --help The files belonging to this database system will be owned by user "gsmith". This user must also own the server process. The database cluster will be initialized with locale "en_US.UTF-8" ... I would like for someone to tell me I'm doing something stupid and this problem isn't really there going back to 9.2. The last potentially related initdb change I found on a quick scan, from around the right time period was the code refactoring of http://www.postgresql.org/message-id/E1TeYOX-0005W4-Kj@gemulon.postgresql.org (there were a few additional initdb commits around then too) -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Hmm - just did a pull now: $ initdb --version initdb (PostgreSQL) 9.3devel $ initdb --help initdb initializes a PostgreSQL database cluster. Usage: initdb [OPTION]... [DATADIR] ...[snipped rest of help output] So looks like something odd you are doing - are you using any unusual build options? Cheers Mark On 27/02/13 11:16, Greg Smith wrote: > Here's a happy initdb on 9.1 providing help: > > $ psql --version > psql (PostgreSQL) 9.1.8 > $ /usr/pgsql-9.1/bin/initdb --help > initdb initializes a PostgreSQL database cluster. > Usage: > initdb [OPTION]... [DATADIR] ... > > Here's what I get on the latest repo: > > $ psql --version > psql (PostgreSQL) 9.3devel > $ initdb --help > The files belonging to this database system will be owned by user "gsmith". > This user must also own the server process. > The database cluster will be initialized with locale "en_US.UTF-8" ... > > initdb --version does the same thing for me: ignores the command line > and just goes onward to create a new cluster. I checked a random, not > current 9.2 install and saw the same issue existed on that version too: > > $ psql --version > psql (PostgreSQL) 9.2.1 > $ initdb --help > The files belonging to this database system will be owned by user "gsmith". > This user must also own the server process. > The database cluster will be initialized with locale "en_US.UTF-8" ... > > I would like for someone to tell me I'm doing something stupid and this > problem isn't really there going back to 9.2. The last potentially > related initdb change I found on a quick scan, from around the right > time period was the code refactoring of > http://www.postgresql.org/message-id/E1TeYOX-0005W4-Kj@gemulon.postgresql.org > (there were a few additional initdb commits around then too) >
Greg Smith <greg@2ndQuadrant.com> writes:
> $ initdb --help
> The files belonging to this database system will be owned by user "gsmith".
Hm. Works as expected for me. What platform is this exactly?
regards, tom lane
On 2/26/13 6:01 PM, Tom Lane wrote: > Greg Smith <greg@2ndQuadrant.com> writes: >> $ initdb --help >> The files belonging to this database system will be owned by user "gsmith". > > Hm. Works as expected for me. What platform is this exactly? The broken one is OS X Lion 10.7.5, main build toolchain provided by Apple's development tools, and Homebrew used to install the missing libraries (zlib etc.) I had been beating my head against the wall asking why initdb didn't work for so long today, I didn't even think this could be a platform specific issue. I don't have any other OS X version installed here to test if this is specific to Lion or not. The working 9.1 install wasn't exactly the same OS, and now that I match that up perfectly it's also broken too. So whatever is going wrong isn't specific to 9.2+ at all; that was my bad. I attached a config.log from the latest 9.3 build if that helps anyone. On a tangent to this, making this more difficult is that there is something else weird about 9.2 on this Mac not defaulting to a small enough block of shared memory too: DETAIL: Failed system call was shmget(key=1, size=2072576, 03600). HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter. You can either reduce the request size or reconfigure the kernel with larger SHMALL. To reduce the request size (currently 2072576 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections. That one doesn't show up in 9.1, and it's gone in 9.3, presumably due to the larger shared memory allocation changes there. I can chase that problem down on my own. The initdb thing left me grasping because I don't know as much as I'd like about autoconf or command line processing trivia. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Attachment
On 2/26/13 5:51 PM, Mark Kirkwood wrote: > So looks like something odd you are doing - are you using any unusual > build options? The unusual part looks to be the build environment or libraries of this Mac I'm trying to use. The build options are the normal boring set: CONFIGURE = '--prefix=/Users/gsmith/pgwork/inst/latest' '--enable-depend' '--enable-thread-safety' '--enable-cassert' '--enable-debug' CC = gcc CPPFLAGS = CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g CFLAGS_SL = LDFLAGS = -L../../../src/common -Wl,-dead_strip_dylibs LDFLAGS_EX = LDFLAGS_SL = LIBS = -lpgport -lpgcommon -lz -lreadline -lm VERSION = PostgreSQL 9.3devel I included the config.log in my last message, here's the simple output of that: cd . && ./config.status --recheck running CONFIG_SHELL=/bin/sh /bin/sh ./configure --prefix=/Users/gsmith/pgwork/inst/latest --enable-depend --enable-thread-safety --enable-cassert --enable-debug --no-create --no-recursion checking build system type... x86_64-apple-darwin11.4.2 checking host system type... x86_64-apple-darwin11.4.2 checking which template to use... darwin checking whether to build with 64-bit integer date/time support... yes checking whether NLS is wanted... no checking for default port number... 5432 checking for block size... 8kB checking for segment size... 1GB checking for WAL block size... 8kB checking for WAL segment size... 16MB checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc supports -Wdeclaration-after-statement... yes checking whether gcc supports -Wendif-labels... yes checking whether gcc supports -Wmissing-format-attribute... yes checking whether gcc supports -Wformat-security... yes checking whether gcc supports -fno-strict-aliasing... yes checking whether gcc supports -fwrapv... yes checking whether gcc supports -fexcess-precision=standard... no checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... yes checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with GSSAPI support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with LDAP support... no checking whether to build with Bonjour support... no checking whether to build with OpenSSL support... no checking whether to build with SELinux support... no checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for ranlib... ranlib checking for strip... strip checking whether it is possible to strip libraries... yes checking for ar... ar checking for a BSD-compatible install... /usr/bin/install -c checking for tar... /usr/bin/tar checking whether ln -s works... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking for a thread-safe mkdir -p... config/install-sh -c -d checking for bison... /usr/bin/bison configure: using bison (GNU Bison) 2.3 checking for flex... /usr/bin/flex configure: using flex 2.5.35 Apple(flex-31) checking for perl... /usr/bin/perl configure: using perl 5.12.3 checking for main in -lm... yes checking for library containing setproctitle... no checking for library containing dlopen... none required checking for library containing socket... none required checking for library containing shl_load... no checking for library containing getopt_long... none required checking for library containing crypt... none required checking for library containing fdatasync... none required checking for library containing gethostbyname_r... no checking for library containing shmget... none required checking for library containing readline... -lreadline checking for inflate in -lz... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking crypt.h usability... no checking crypt.h presence... no checking for crypt.h... no checking dld.h usability... no checking dld.h presence... no checking for dld.h... no checking fp_class.h usability... no checking fp_class.h presence... no checking for fp_class.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking ieeefp.h usability... no checking ieeefp.h presence... no checking for ieeefp.h... no checking ifaddrs.h usability... yes checking ifaddrs.h presence... yes checking for ifaddrs.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/ipc.h usability... yes checking sys/ipc.h presence... yes checking for sys/ipc.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/pstat.h usability... no checking sys/pstat.h presence... no checking for sys/pstat.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/sem.h usability... yes checking sys/sem.h presence... yes checking for sys/sem.h... yes checking sys/shm.h usability... yes checking sys/shm.h presence... yes checking for sys/shm.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/sockio.h usability... yes checking sys/sockio.h presence... yes checking for sys/sockio.h... yes checking sys/tas.h usability... no checking sys/tas.h presence... no checking for sys/tas.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/ucred.h usability... yes checking sys/ucred.h presence... yes checking for sys/ucred.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking ucred.h usability... no checking ucred.h presence... no checking for ucred.h... no checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for net/if.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking for netinet/tcp.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking whether byte ordering is bigendian... no checking for an ANSI C-conforming const... yes checking for inline... inline checking for quiet inline (no complaint if unreferenced)... yes checking for preprocessor stringizing operator... yes checking for flexible array members... yes checking for signed types... yes checking for working volatile... yes checking for __func__... yes checking for _Static_assert... no checking for __builtin_types_compatible_p... yes checking for __builtin_constant_p... yes checking for __builtin_unreachable... no checking for __VA_ARGS__... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... yes checking for tzname... yes checking for union semun... yes checking for struct sockaddr_un... yes checking for struct sockaddr_storage... yes checking for struct sockaddr_storage.ss_family... yes checking for struct sockaddr_storage.__ss_family... no checking for struct sockaddr_storage.ss_len... yes checking for struct sockaddr_storage.__ss_len... no checking for struct sockaddr.sa_len... yes checking for struct addrinfo... yes checking for intptr_t... yes checking for uintptr_t... yes checking for long long int... yes checking for locale_t... yes (in xlocale.h) checking for struct cmsgcred... no checking for struct option... yes checking for z_streamp... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking size of off_t... 8 checking for int timezone... yes checking types of arguments for accept()... int, int, struct sockaddr *, socklen_t * checking whether gettimeofday takes only one argument... no checking for cbrt... yes checking for dlopen... yes checking for fdatasync... yes checking for getifaddrs... yes checking for getpeerucred... no checking for getrlimit... yes checking for mbstowcs_l... yes checking for memmove... yes checking for poll... yes checking for pstat... no checking for readlink... yes checking for setproctitle... no checking for setsid... yes checking for sigprocmask... yes checking for symlink... yes checking for sync_file_range... no checking for towlower... yes checking for utime... yes checking for utimes... yes checking for wcstombs... yes checking for wcstombs_l... yes checking for fseeko... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for posix_fadvise... no checking whether posix_fadvise is declared... no checking whether fdatasync is declared... no checking whether strlcat is declared... yes checking whether strlcpy is declared... yes checking whether F_FULLFSYNC is declared... yes checking for struct sockaddr_in6... yes checking for PS_STRINGS... no checking for snprintf... yes checking for vsnprintf... yes checking whether snprintf is declared... yes checking whether vsnprintf is declared... yes checking for isinf... yes checking for crypt... yes checking for fls... yes checking for getopt... yes checking for getrusage... yes checking for inet_aton... yes checking for random... yes checking for rint... yes checking for srandom... yes checking for strerror... yes checking for strlcat... yes checking for strlcpy... yes checking for unsetenv... yes checking for getpeereid... yes checking for getaddrinfo... yes checking for getopt_long... yes checking for sigsetjmp... yes checking whether sys_siglist is declared... yes checking for syslog... yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking for opterr... yes checking for optreset... yes checking for strtoll... yes checking for strtoull... yes checking for builtin locking functions... yes checking for rl_completion_append_character... yes checking for rl_completion_matches... yes checking for rl_filename_completion_function... yes checking for append_history... no checking for history_truncate_file... yes checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking whether pthreads work with -Kthread... yes checking whether pthreads work with -kthread... yes checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking whether pthreads work with -pthreads... yes checking whether pthreads work with -mthreads... no checking for the pthreads library -lpthread... yes checking whether pthreads work with --thread-safe... no checking whether pthreads work with -mt... no checking for the pthreads library -lpthreadGC2... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strerror_r... yes checking for getpwuid_r... yes checking for gethostbyname_r... no checking whether getpwuid_r takes a fifth argument... yes checking whether strerror_r returns int... yes checking test program... ok checking whether long int is 64 bits... yes checking size of void *... 8 checking size of size_t... 8 checking size of long... 8 checking whether to build with float4 passed by value... yes checking whether to build with float8 passed by value... yes checking alignment of short... 2 checking alignment of int... 4 checking alignment of long... 8 checking alignment of double... 8 checking for int8... no checking for uint8... no checking for int64... no checking for uint64... no checking for sig_atomic_t... yes checking for POSIX signal interface... yes checking for working memcmp... yes checking for onsgmls... no checking for nsgmls... no checking for openjade... no checking for jade... no checking for DocBook V4.2... no checking for DocBook stylesheets... no checking for collateindex.pl... no checking for xsltproc... xsltproc checking for osx... no checking for sgml2xml... no checking for sx... no checking thread safety of required library functions... yes checking whether gcc supports -Wl,-dead_strip_dylibs... yes configure: using compiler=i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g configure: using CPPFLAGS= configure: using LDFLAGS= -Wl,-dead_strip_dylibs
On 27/02/13 12:41, Greg Smith wrote: > On 2/26/13 5:51 PM, Mark Kirkwood wrote: >> So looks like something odd you are doing - are you using any unusual >> build options? > > The unusual part looks to be the build environment or libraries of this > Mac I'm trying to use. The build options are the normal boring set: > > CONFIGURE = '--prefix=/Users/gsmith/pgwork/inst/latest' > '--enable-depend' '--enable-thread-safety' '--enable-cassert' > '--enable-debug' This might be a red herring - but I recall having problems using --enable-depend on older OSX versions (10.5 I think), so *maybe* worth seeing if leaving that option off and doing a distclean+rebuild changes anything. Cheers Mark
Greg Smith <greg@2ndQuadrant.com> writes:
> On 2/26/13 6:01 PM, Tom Lane wrote:
>> Greg Smith <greg@2ndQuadrant.com> writes:
>>> $ initdb --help
>>> The files belonging to this database system will be owned by user "gsmith".
>> Hm. Works as expected for me. What platform is this exactly?
> The broken one is OS X Lion 10.7.5, main build toolchain provided by
> Apple's development tools, and Homebrew used to install the missing
> libraries (zlib etc.) I had been beating my head against the wall
> asking why initdb didn't work for so long today, I didn't even think
> this could be a platform specific issue. I don't have any other OS X
> version installed here to test if this is specific to Lion or not.
[ scratches head... ] 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?
regards, tom lane
On 26 February 2013 22:16, Greg Smith <greg@2ndquadrant.com> wrote: > Here's what I get on the latest repo: > > $ psql --version > psql (PostgreSQL) 9.3devel > $ initdb --help > The files belonging to this database system will be owned by user "gsmith". > This user must also own the server process. > The database cluster will be initialized with locale "en_US.UTF-8" ... What does "which initdb" give you? And is it only initdb with the issue? Have you tested it with pg_ctl? -- Thom
On 2/26/13 6:57 PM, Mark Kirkwood wrote: > This might be a red herring - but I recall having problems using > --enable-depend on older OSX versions (10.5 I think), so *maybe* worth > seeing if leaving that option off and doing a distclean+rebuild changes > anything. I toggled off both that and not expliciting enabling enable-thread-safety with no change. For Thom's question, these are all hitting the Postgres I compiled, and yes other tools like pg_ctl seem fine: $ which pg_ctl /Users/gsmith/pgwork/inst/latest/bin/pg_ctl $ pg_ctl --version pg_ctl (PostgreSQL) 9.3devel $ which initdb /Users/gsmith/pgwork/inst/latest/bin/initdb $ initdb --version Database cluster already exists in /Users/gsmith/pgwork/data/latest -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
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
On 2/26/13 9:18 PM, Greg Smith wrote: > $ 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) Two last bits of trivia and I'll stop talking to myself. You can get the full list of things this dynamic library then links to like this: $ otool -lTv /usr/lib/libSystem.B.dylib | grep "(offset" name /usr/lib/libSystem.B.dylib (offset 24) name/usr/lib/system/libcache.dylib (offset 24) name /usr/lib/system/libcommonCrypto.dylib (offset 24) ... There's a bit more information about all the libraries squashed into this one on OS X at http://0xfe.blogspot.com/2006/03/qa-how-os-x-executes-applications.html It is also worth nothing that otool is part of the developer tools for OS X, not the base system. Features like DYLD_PRINT_LIBRARIES look like they work on any system though. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com