Closing -- no need for Patrik to test this now that I could reproduce the bug
and the fix.

Never mind, I was expecting a compilation error, when of course the error would
appear at runtime. I do get the runtime error as expected.

With issues like these, it would be neat to have at least four build bots to
test all combinations of 32-bit and 64-bit compiles with 32-bit and 64-bit machines.

> Strangely enough, I can't reproduce this on my new
> 64-bit machine, which build a 64-bit executable without complaints once I got
> rid of the "-m32" options. 

Strange. I don't have access to a 64-bit system, but I checked that
any_cast won't convert int64s to int32s. And there are very few
64-bit-systems where int=int64.

Thanks for the analysis! Strangely enough, I can't reproduce this on my new
64-bit machine, which build a 64-bit executable without complaints once I got
rid of the "-m32" options. Oh well.

Fixed and pushed. Patrik, can you verify that the current code works after
getting rid of the "-m32" entries?

(BTW, last time we tested this, -m64 almost doubles memory consumption in some
configurations. So I wouldn't use this for serious benchmarking.)

So making the template parameters explicit in the way Patrik did should
be enough.

Probable problem:
The iterator arithmetic in "opts.set(k, it - enumeration.begin());". The
return type of "it - enumeration.begin()" is of type ptrdiff_t, which I
think is int64 on 64bit systems. But int=int32, even on 64bit systems.
But boost::any_cast only works when the types match exactly.

Moritz, any ideas?

I had reason to compile FD on a 64-bit machine that was not set up to
cross-compile for 32-bit. Just removing the -m32 flags from the Makefiles were
enough to make it compile, but the resulting binary exhibited a strange bug: The
any_cast in Options::get failed for enums (in particular, for the cost_type
option, both when the option was given explicitly and when it was not, i.e.,
when using the default value).

To fix it, I replaced the two calls to opts.set(k, ...) in
OptionParser::add_enum_option by opts.set<int>(k, ...). After this, the planner
works as normal.

No idea why this behaviour showed up only in the 64-bit version. (It may have
nothing to do with that, I guess, could be a different version of boost
libraries or something.)