The program does not crash if: (1) I don't link to boost.thread, or remove boost/thread.hpp from main.cpp. (2) I don't 'strip' the executable before running it.

The error is independent of whether I link statically or dynamically, and whether I compile in 'debug' or 'release' mode. (Though it doesn't appear in 'debug' mode unless I strip the executable myself.)

The error doesn't depend on coordinate matrix, it happens just the same if I use a ublas::vector (and include the relevant header.)

Anyway, the above is about as small an example as I can figure out, and I certainly don't have the skills to go any further.

The problem is that 'strip' should not be run without options---doing this strips too much out of the binary. Running strip with the -S and -x options seems to be appropriate on OS X but I don't have the expertise to verify this. (Thanks to Zeljko Vrba for figuring this out.)

Do I understand correctly that if you build in debug mode, application works, but if you strip it with just 'strip', it crashes? What happens if you strip with "strip -u -r"? Does the application actually work if stripped with "strip -S -x"? Can you run 'nm' on a binary that crashes and a binary that does not, and post both outputs here?

which surely looks very scary. I was not able to find a definite explanation why strip breaks a binary like this, so I presume we're using strip in some way it was not meant to, which breaks on newer OSX. But to make progress, I've switched to use -S -x. Feel free to open another ticket if you find a "better" way to strip binaries.