I think this worked on linux because `pthread_mutexattr_t` is not dynamically allocated on linux, but it is on OpenBSD. Also, you'll only hit this bug if you compile with a headers-only boost library, because otherwise you'll use boost's thread implementation and not this stub.

That looks like it was written by someone who reads documentation. I integrated it already, even if it does not fix this particular issue, it's clearly more correct.
Following tradition: How do you want to be credited in AUTHORS?

It's still a threading issue. Isn't there an option to build without multi-threading? I know it was there at some time, but it may have been removed (I also remember that the threading library we used stopped being maintained, and there were changes because of that).

Also, correct me if I'm wrong but doesn't boost provide some multithreading capabilities? If so, I could try compiling without boost although I'm guessing boost is used for more than just multithreading?

You won't be able to compile arma completely without boost, some of its libraries are required (shared_ptr and any are the ones I remember). boost-threads is opional; the code tux fixed was in the fallback part that is only active if you don't have boost-threads installed.

Maybe the compiler doesn't eat the "std::unique_ptr< type > variable" declaration with the spaces there; could be confusing it with the < and > operators. Before the last code change it used std::auto_ptr there which doesn't seem to have </> operators at all.

No, whitespace can't be the issue. It's unique_ptr is new in the C++11 standard, and gcc assumes we're using an earlier one. Odd. There should be a -std=c++11 command line switch indicating our preference there, configure is supposed to add it. And configure is supposed to automatially get rerun if it changes...
Can you manually rerun configure and see if that fixes things? If not, please post configure.log.

Background: auto_ptr had really unintuitive semantics; it's copy operator had a non-const-reference source argument and invalidated the source. Therefore was deprecated in C++11 now that move semantics are awailable. GCC 6 now uses C++11 as default standard, that's what raised the issue in the form of a torrent of warnings. Plus, C++11 is an awesome step forward and should be supported everywhere by now.

By the way, code::blocks compilation on windows 0.4 should fail right now with the same error. I need to adapt the project settings still.

Ok, so still no joy but I think I've found the (or at least a) problem. OpenBSD uses gcc/g++ version 4.2.1 by default which seems to date from 2007 (too early for C++11). I'll install the newest g++ from OpenBSD's packages repository and see if that supports C++11.

Just for you to chew over while I'm doing that, here is config.log, which I've called config.txt because "the extension log is not allowed"