Bug 213223 - databases/db6 fails to compile on ARMv6+
Summary: databases/db6 fails to compile on ARMv6+
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Many People
Assignee: Matthias Andree
URL:
Keywords:
Depends on:
Blocks: 213167
  Show dependency treegraph
 
Reported: 2016-10-05 06:58 UTC by Matthias Andree
Modified: 2016-10-06 18:00 UTC (History)
3 users (show)

See Also:
mandree: maintainer-feedback+


Attachments
armv6 patch (1.45 KB, patch)
2016-10-05 12:05 UTC, mikael.urankar
mandree: maintainer-approval-
Details | Diff
build log (208.81 KB, text/x-log)
2016-10-05 12:20 UTC, mikael.urankar
no flags Details
armv6 patch (963 bytes, patch)
2016-10-05 18:02 UTC, mikael.urankar
mandree: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree freebsd_committer 2016-10-05 06:58:10 UTC
databases/db6 fails to compile on ARM with

===>  Building for db6-6.2.23_1
gmake[1]: Entering directory '/var/tmp/usr/ports/databases/db6/work/db-6.2.23/build_unix'
./libtool --mode=compile cc -c -I. -I./../src  -D_THREAD_SAFE -O3 -pipe  -fno-strict-aliasing  ../lang/db185/db185.c
libtool: compile:  cc -c -I. -I./../src -D_THREAD_SAFE -O3 -pipe -fno-strict-aliasing ../lang/db185/db185.c  -fPIC -DPIC -o .libs/db185.o
../lang/db185/db185.c:71:7: warning: case value not in enumerated type 'DBTYPE' [-Wswitch]
        case 0:                                 /* DB_BTREE */
             ^
1 warning generated.
libtool: compile:  cc -c -I. -I./../src -D_THREAD_SAFE -O3 -pipe -fno-strict-aliasing ../lang/db185/db185.c -o db185.o >/dev/null 2>&1
./libtool --mode=compile cc -c -I. -I./../src  -D_THREAD_SAFE -O3 -pipe  -fno-strict-aliasing  ../src/mutex/mut_tas.c
libtool: compile:  cc -c -I. -I./../src -D_THREAD_SAFE -O3 -pipe -fno-strict-aliasing ../src/mutex/mut_tas.c  -fPIC -DPIC -o .libs/mut_tas.o
../src/mutex/mut_tas.c:203:3: error: instruction requires: data-barriers
                MEMBAR_ENTER();
                ^
./../src/dbinc/mutex_int.h:511:23: note: expanded from macro 'MEMBAR_ENTER'
        ({ __asm__ volatile ("dsb"); })
                             ^
<inline asm>:1:2: note: instantiated into assembly here
        dsb
        ^
../src/mutex/mut_tas.c:445:3: error: instruction requires: data-barriers
                MEMBAR_ENTER();
                ^
./../src/dbinc/mutex_int.h:511:23: note: expanded from macro 'MEMBAR_ENTER'
        ({ __asm__ volatile ("dsb"); })
                             ^
<inline asm>:1:2: note: instantiated into assembly here
        dsb
        ^
../src/mutex/mut_tas.c:645:4: error: instruction requires: data-barriers
                        MEMBAR_EXIT();
                        ^
./../src/dbinc/mutex_int.h:513:23: note: expanded from macro 'MEMBAR_EXIT'
        ({ __asm__ volatile ("dsb"); })
                             ^
<inline asm>:1:2: note: instantiated into assembly here
        dsb
        ^
../src/mutex/mut_tas.c:649:4: error: instruction requires: data-barriers
                        MEMBAR_EXIT();
                        ^
./../src/dbinc/mutex_int.h:513:23: note: expanded from macro 'MEMBAR_EXIT'
        ({ __asm__ volatile ("dsb"); })
                             ^
<inline asm>:1:2: note: instantiated into assembly here
        dsb
        ^
4 errors generated.
gmake[1]: *** [Makefile:2499: mut_tas.lo] Error 1
gmake[1]: Leaving directory '/var/tmp/usr/ports/databases/db6/work/db-6.2.23/build_unix'
*** Error code 1
Comment 1 Matthias Andree freebsd_committer 2016-10-05 07:00:58 UTC
+++ Copying relevant comment from Bug #213167 +++

Does it help if you add -march=armv6 or similar to the CFLAGS in your build environment, possibly through the poudriere-based etc/make.conf replacement?  

Not knowing ARM well, chances are that the compiler/assembler refuses to generate the DMB and DSB instructions because they aren't available in v5 and older processors and the build apparently has not permitted code that runs only on v6 or newer.

If so, the FreeBSD-ARM guys may want to set that globally in the ports frameworks.


Also note that cross-compiles may fail because the configure script uses run-time checks that are unavailable on amd64, and I haven't checked what assumptions these make for cross-compilation, so we may need to override these manually, or add --with-mutex=ARM/gcc-assembly to CONFIGURE_ARGS on ARMv6 and newer.  In doubt, please try to compile natively on ARM.
Comment 2 Matthias Andree freebsd_committer 2016-10-05 07:01:40 UTC
+++ Triggering commit info +++

Author: mandree
Date: Tue Oct  4 09:32:48 UTC 2016
New revision: 423245
URL: https://svnweb.freebsd.org/changeset/ports/423245

Log:
  Avoid POSIX mutexes on armv6* and aarch64.

  db6 switched from the stpb-based mutexes that db5 used to ldrex/strex.

  PR:		213167 (related)

Changes:
  head/databases/db6/Makefile
Comment 3 mikael.urankar 2016-10-05 12:05:06 UTC
Created attachment 175444 [details]
armv6 patch

dsb is an armv7 instruction and we are building for armv6.
We need to use __asm __volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0) : "memory") on armv6
See attached patch
Comment 4 mikael.urankar 2016-10-05 12:20:27 UTC
Created attachment 175445 [details]
build log
Comment 5 Vick Khera 2016-10-05 16:16:39 UTC
I can confirm that the proposed patch does result in a completed build of db6 on armv6.

I build using poudriere with qemu emulation. I cannot use the native cross-build tools (the -x option to poudriere jail) because my jail and host are not the same release version.

I tested the resulting db6 library as part of netatalk3 on a Raspberry Pi 2, and it seems to be working just fine. I have no real way to validate that the actual mutex is functional as I do not know the internals of how DB6 uses them to lock out concurrent access.

A big thanks to both of you for looking into this and finding a great solution! I really appreciate it, and I will sleep better knowing my laptop is safely backed up on a reliable freebsd-powered Raspberry Pi NAS.
Comment 6 mikael.urankar 2016-10-05 18:02:05 UTC
Created attachment 175451 [details]
armv6 patch

or we can do something like that, it's basically the same, I don't know which one you prefer.
Comment 7 Vick Khera 2016-10-05 18:34:10 UTC
Personally, I prefer pulling in the system atomic.h header, as that will theoretically always be "right", and you no longer have to worry about keeping your copy "right".

But I'm not in any position to decide definitively for the project.
Comment 8 Matthias Andree freebsd_committer 2016-10-05 19:25:29 UTC
Comment on attachment 175451 [details]
armv6 patch

It appears that the latter patch would be the more portable, because we appear to support all ARM versions that way, (1) <= v5 (2) v6 (3) v7+.
Comment 9 commit-hook freebsd_committer 2016-10-05 20:17:48 UTC
A commit references this bug:

Author: mandree
Date: Wed Oct  5 20:17:39 UTC 2016
New revision: 423388
URL: https://svnweb.freebsd.org/changeset/ports/423388

Log:
  ARM: for mutexes, use machine/atomic.h primitives

  The previous approach only worked on ARMv7+, this should now permit
  build and use with environments shared between processes on a wider set
  of ARM architectures.

  Bump PORTREVISION.

  PR:		213223
  Submitted by:	mikael.urankar@gmail.com

Changes:
  head/databases/db6/Makefile
  head/databases/db6/files/patch-src_dbinc_mutex__int.h
Comment 10 Matthias Andree freebsd_committer 2016-10-05 20:18:23 UTC
I have committed the latter, Vivek, could you check if the _2 revision of the port builds and works for you? Thanks.
Comment 11 Matthias Andree freebsd_committer 2016-10-05 20:23:08 UTC
Mikael, many thanks for your patches - much appreciated!
Comment 12 Vick Khera 2016-10-06 17:30:42 UTC
I confirm that the final patch for revision 2 builds in my environment, and works on the Raspberry Pi 2.

Thanks again for all your help, both of you!

As an aside, should netatalk3 be marked "broken" for DB < 6 or can this same patch to use atomic.h work there?
Comment 13 Matthias Andree freebsd_committer 2016-10-06 18:00:53 UTC
Please repost the question from comment #12 in Bug #213167.