Re: PostgreSQL cannot be compiled on RISC-V
От | Richard W.M. Jones |
---|---|
Тема | Re: PostgreSQL cannot be compiled on RISC-V |
Дата | |
Msg-id | 20161120173322.GA10475@redhat.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL cannot be compiled on RISC-V ("Richard W.M. Jones" <rjones@redhat.com>) |
Ответы |
Re: PostgreSQL cannot be compiled on RISC-V
|
Список | 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 по дате отправления: