From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Richard W(dot)M(dot) Jones" <rjones(at)redhat(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PostgreSQL cannot be compiled on RISC-V |
Date: | 2016-11-20 19:45:18 |
Message-ID: | 11046.1479671118@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Richard W.M. Jones" <rjones(at)redhat(dot)com> writes:
> On Sun, Nov 20, 2016 at 01:02:51PM -0500, Tom Lane wrote:
>> Hmm, makes me wonder if the spinlock primitives actually work ...
> Yes, my thought too.
> With MAX_CONNECTIONS=1 only 5 tests fail, and reliably too:
> opr_sanity ... FAILED
> test errors ... FAILED
> psql_crosstab ... FAILED
> select_views ... FAILED
> largeobject ... FAILED (test process exited with exit code 2)
That's a smoking gun then. Your GCC builtins don't work.
>> Assuming that you've got working core dump support and gdb,
>> getting stack traces from some of the crashes would be useful info.
> Agreed. Unfortunately there's no gdb yet, and as above no core dumps
> in any case.
Hm. You could look at the regression.diffs file to get more info
about what's happening. But TBH, if you don't have GDB working
yet, it doesn't seem like making Postgres work is a higher priority
problem than that.
Once you've got GDB working, I'd be willing to help investigate,
if you can give me ssh access to a RISC-V box with a devel
environment installed. Before that, it seems like a pretty
back-burner problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard W.M. Jones | 2016-11-20 19:54:00 | Re: PostgreSQL cannot be compiled on RISC-V |
Previous Message | Tom Lane | 2016-11-20 19:35:42 | Re: PostgreSQL cannot be compiled on RISC-V |