Re: PostgreSQL cannot be compiled on RISC-V - Mailing list pgsql-bugs

From Richard W.M. Jones
Subject Re: PostgreSQL cannot be compiled on RISC-V
Date
Msg-id 20161120173322.GA10475@redhat.com
Whole thread Raw
In response to Re: PostgreSQL cannot be compiled on RISC-V  ("Richard W.M. Jones" <rjones@redhat.com>)
Responses Re: PostgreSQL cannot be compiled on RISC-V
List pgsql-bugs
On Sun, Nov 20, 2016 at 03:09:05PM +0000, Richard W.M. Jones wrote:
> On Sat, Nov 19, 2016 at 10:08:07PM -0500, Tom Lane wrote:
> > "Richard W.M. Jones" <rjones@redhat.com> writes:
> > > ../../../src/include/storage/s_lock.h:890:2: error: #error PostgreSQL does not have native spinlock support on
thisplatform. To continue the compilation, rerun configure using --disable-spinlocks. However, performance will be
poor.Please report this to pgsql-bugs@postgresql.org. 
> >
> > Hi Richard,
> >
> > What's a RISC-V, and can you provide some gcc assembler implementing
> > spinlocks for it?  See commentary and code for other platforms in
> > src/include/storage/s_lock.h.
>
> That attached patch allows PostgreSQL to compile successfully.  I'm
> still examining the test failures, but I think they are irrelevant to
> this.
>
> Please note that you also need to update config/config.{sub,guess} to
> the latest versions from upstream
> (https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html)
> since your current versions are too old to understand the riscv{32,64}
> architectures.

I'm happy with the patch I previously attached, and I don't think it
would be controversial to apply it to upstream PostgreSQL now, along
with updating config.guess/config.sub.  I didn't test spinlocks, but
if there was a bug in the GCC builtin, then we would fix it in GCC.
(In fact, why not use the GCC builtin every time PostgreSQL is
compiled with GCC?)

For the sake of full disclosure, the test suite is rather "crashy",
with about half of the tests failing.  Basic database creation,
creating tables, etc all works, but the detailed tests fail with "test
process exited with exit code 2" often.

None of this is surprising as the entire toolchain is pre-alpha.

I found that dialing MAX_CONNECTIONS down to 2 or 3 helps.

What would be helpful is to get more detail on how the tests fail.  I
don't even know if it is the client or server side which fails
(although I assume the server, because `psql' will exit with code 2 if
it loses the network connection).  Is there some way to run tests with
lots of extra verbosity?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

pgsql-bugs by date:

Previous
From: Ingbert Jüdt (privat)
Date:
Subject: Re: BUG #14425: Installation issues
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL cannot be compiled on RISC-V