Release 6 and 6.*.* support ARM on Linux but was never tested on the Pi (it didn't exist at the time of the release) - so it certainly is possible that there are compile problems on that platform.
That particular error is to do with the code in the abstraction layer which performs a DWCAS (double-word compare-and-swap). On ARM, that function actually contains assembly code - rather than using the GCC atomic intrinsics - because there is GCC only has instrincs for *single-word* compare-and-swap.
(In fact, I later realised, if you use an int long long unsigned, which is 64 bit, GCC *will* perform the correct double-word CAS! and that's how 7.0.0 does things, and why ARM64 isn't yet supported - I'll need assembly code for that, and I've not written it yet).
So it sounds like that assembly code is not working on the Pi, which is unexpected - I would have thought it should be okay.
Fortunately, I *have* a Pi2 model B, so I should be able now to reproduce the error.
In general, I profoundly recommend you to move up to release 6.1.1 (although this will still have the same compiler problem - it will not fix the problem in hand). Release 6 *is not right* - it does not correctly use compiler and memory barriers and so in principle is working correctly by chance - even though in practise, the chance of something going wrong is very, very small, and even then requires high data structure load. Nevertheless - there should be *no* chance of error.
Regarding your continued use of release 6, I may be wrong, but I think there will be two reasons for this; firstly, the work to change the code base over, secondly, testing. With regard to the first, 6.1.1 is API identical to 6. It is only a matter of a global search and replace for variable type names and function names. With regard to the second, you will need to retest, as the code has changed - but the changes *are and only are* the addition of compiler and memory barriers.
Unless I have blundered and inadvertantly introduced other changes, the addition of compiler and memory barriers *almost certainly cannot break functioning code*. The only way this could occur is if the code was originally working only *because* the compiler or processor were re-ordering when they should not be, and stopping them doing so revealed a fault!
With regard to the error in hand, I will of course most likely need to make code changes (although there's a small chance it might only be a makefile change) which means you will need a modified version of the code - the fact that the abstraction_dwcas() function has changed would in principle also induce the need for the same testing which would be required by moving to 6.1.1.
As it is, ideally (and probably anyway, even if you get your own custom version of 6) I would look to release 6.0.2 and 6.1.2, which will contain the fix for Raspberry Pi.
Either way, what I need to do now is fix the bug. I'll let you know when it's done; it should be today, except I have to figure out a way to get my Pi up and running, and I don't think there's a switch here for the ethernet cable (that's the main problem!)