Re: initdb failing on REL9_5_STABLE with exit code 132...

On 07/01/2016 03:34 PM, Tom Lane wrote:
> Bob Cochran <pgsql(at)mindchasers(dot)com> writes:
>> I just built REL9_5_STABLE using an embedded Linux install 4.1.8.
>> I configured as follows: configure --with-python --with-openssl
>> --enable-debug
>> When I run initdb, I get the following:
>> creating subdirectories ... ok
>> selecting default max_connections ... 100
>> selecting default shared_buffers ... 128MB
>> selecting dynamic shared memory implementation ... posix
>> creating configuration files ... ok
>> creating template1 database in /usr/local/pgsql/data/base/1 ... ok
>> initializing pg_authid ... ok
>> initializing dependencies ... ok
>> creating system views ... ok
>> loading system objects' descriptions ... sh: line 1: 19593 Illegal
>> instruction "/usr/local/pgsql/bin/postgres" --single -F -O -c
>> search_path=pg_catalog -c exit_on_error=true template1 > /dev/null
>> child process exited with exit code 132
> Hm, not much to go on there. In the past, when we've seen crashes at
> this stage, it's frequently meant a compiler bug or at least over-
> aggressive optimization. If you're using a bleeding-edge compiler
> it might be worth backing off the -O level to see what happens.

Thank you Tom. I re-ran configure with "CFLAGS=-Wall .... -O0", and I
was able to successfully run initdb and start the server.

Prior to this, the optimization level was set as O2, and initdb would
fail with error code 132.

So, I can both move forward on my target system, and I suppose I know
now there is a compiler issue. I'll report back if I get some more
info and it's relevant to postgres.

BTW, I'm building on a powerpc64 target with a Yocto-built rootfs from a
master-next branch, so it's sort of on the edge.

Bob

>
> regards, tom lane
>