Some of the patches are more general than just DragonFly support:
1) The bitcoind make target in makefile.unix defines USE_UPNP to 0; however net.cpp among others uses '#ifdef' as the test for miniupnp, which means the upnp headers are always required.
2) main.cpp has:
-char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
g++ 4.4.5 on DragonFly disapproves; the constants are being narrowed from int -> char inside an array initializer. I think the error is correct, though harsh.
3) g++ on DragonFly wants -std=c++0x or -std=gnu++0x; I agree with it -- typed enumerations are used in the source. I don't know why the same g++ version on Linux doesn't require it, though.
4) in db.cpp, make_tuple is meant to resolve to boost::make_tuple; at least in our configuration, it resolves to std::make_tuple, which is not correct. I don't know enough to say what correct behavior is when a template is defined in more than one namespace (std and boost) and both are 'using namespace '-ed. But qualifying it helps.
DragonFly specific stuff:
1) Currently net.cpp, there is an assumption that all BSD systems support SO_NOSIGPIPE; DragonFly doesn't. The test should probably be for SO_NOSIGPIPE.
I knew about the SO_NOSIGPIPE issue ( supported in FreeBSD >5 only. Being that DragonFly is based on the 4.x series i can understand why it's not; but also read somewhere that Open and Net don't either )1) The bitcoind make target in makefile.unix defines USE_UPNP to 0; however net.cpp among others uses '#ifdef' as the test for miniupnp, which means the upnp headers are always required.
2) main.cpp has:
-char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
g++ 4.4.5 on DragonFly disapproves; the constants are being narrowed from int -> char inside an array initializer. I think the error is correct, though harsh.
3) g++ on DragonFly wants -std=c++0x or -std=gnu++0x; I agree with it -- typed enumerations are used in the source. I don't know why the same g++ version on Linux doesn't require it, though.
4) in db.cpp, make_tuple is meant to resolve to boost::make_tuple; at least in our configuration, it resolves to std::make_tuple, which is not correct. I don't know enough to say what correct behavior is when a template is defined in more than one namespace (std and boost) and both are 'using namespace '-ed. But qualifying it helps.
DragonFly specific stuff:
1) Currently net.cpp, there is an assumption that all BSD systems support SO_NOSIGPIPE; DragonFly doesn't. The test should probably be for SO_NOSIGPIPE.
The db.cpp boost issue has been driving me absolutely nuts (usually I can figure such things out with a little poking around make files, etc.).
Anyway, if it's working for you - compiled, all that, I'd be willing to be a 2nd to apply the patches and build on my dragonflybsd system.
