Been running a board for a few weeks here, works pretty well. Generates stunningly little heat, very easy to cool.

To get the BTCMiner software running under BSD, you'll need to build libusbJava (in the USB SDK) and make sure /dev/usb? and /dev/ugen? are accessible.

Have also loaded a custom bitstream (just a clock divider FF chain), to see if it works. Works okay, just remember you need Xilinx Foundation, not Webpack, to use the spartan6 lx150.

Hi,

Sorry, didn't quite follow what you last wrote -- something like a site where getting site.awesome.com/, where the request would stall till a transaction targeting that address arrived, would that be what you're looking for?

Thanks,
--vs;

Incompatible with what? If you download the blockchain from within the client and don't need to share the db with precompiled clients, 4.8 works fine.

Which version of bitcoin are you using? crypter is present in git master.

Also, what Berkeley DB package do you have? /usr/pkg/include/db4 was provided by db4-4.8.30 from pkgsrc.

Works for me on OpenBSD/i386.

The SO_NOSIGPIPE fix is in bitcoin's git master; I submitted it to deal with DragonFly BSD. I've submitted a patch for the MSG_NOSIGNAL definition as well to the list.

But I'm confused as to how it is working on Sparc64; isn't sparc64 a big-endian machine? The C++ bitcoin client isn't supposed to run on BE machines... have you been able to download the blockchain and everything?

Thanks,
-- vs

Yes; was asking to see if they could be hosted at the same place or would have to be elsewhere.

Would you be interested in nightly builds for DragonFly BSD and OpenBSD?

For anyone who has run this design on the LX9 microboard, what sort of hashrate did you get? And how many slices were used (and at what unrolling level?).

Thanks,
-- vs

For those of you mining,

per numerandum nummi 

Let me just post my Makefile here:

# Copyright (c) 2009-2010 Satoshi Nakamoto
# Distributed under the MIT/X11 software license, see the accompanying
# file license.txt or http://www.opensource.org/licenses/mit-license.php.

CXX=g++

WXINCLUDEPATHS=$(shell wx-config --cxxflags)

WXLIBS=$(shell wx-config --libs)

USE_UPNP:=0

DEFS=-std=gnu++0x -DNOPCH -DUSE_SSL

# for boost 1.37, add -mt to the boost libraries
LIBS= \
 -L/usr/pkg/lib \
 -Wl,-Bstatic \
   -l boost_system \
   -l boost_filesystem \
   -l boost_program_options \
   -l boost_thread \
   -l db4_cxx \
   -l ssl \
   -l crypto

DEFS += -UUSE_UPNP -I/usr/pkg/include -I/usr/pkg/include/db4

LIBS+= \
 -Wl,-Bdynamic \
   -l gthread-2.0 \
   -l z \
   -l pthread


DEBUGFLAGS=-g -D__WXDEBUG__
CXXFLAGS=-O2 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS)
HEADERS=headers.h strlcpy.h serialize.h uint256.h util.h key.h bignum.h base58.h \
    script.h db.h net.h irc.h keystore.h main.h wallet.h rpc.h uibase.h ui.h noui.h \
    init.h crypter.h

OBJS= \
    obj/util.o \
    obj/script.o \
    obj/db.o \
    obj/net.o \
    obj/irc.o \
    obj/keystore.o \
    obj/main.o \
    obj/wallet.o \
    obj/rpc.o \
    obj/init.o \
    obj/crypter.o \
    cryptopp/obj/sha.o \
    cryptopp/obj/cpu.o


all: bitcoin


obj/%.o: %.cpp $(HEADERS)
   $(CXX) -c $(CXXFLAGS) $(WXINCLUDEPATHS) -DGUI -o $@ $<

cryptopp/obj/%.o: cryptopp/%.cpp
   $(CXX) -c $(CXXFLAGS) -O3 -o $@ $<

bitcoin: $(OBJS) obj/ui.o obj/uibase.o
   $(CXX) $(CXXFLAGS) -o $@ $^ $(WXLIBS) $(LIBS)


obj/nogui/%.o: %.cpp $(HEADERS)
   $(CXX) -c $(CXXFLAGS) -o $@ $<

bitcoind: $(OBJS:obj/%=obj/nogui/%)
   $(CXX) $(CXXFLAGS) -o $@ $^ $(LIBS)

obj/test/%.o: test/%.cpp $(HEADERS)
   $(CXX) -c $(CFLAGS) -o $@ $<

test_bitcoin: obj/test/test_bitcoin.o
   $(CXX) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(LIBS) -lboost_unit_test_framework

clean:
   -rm -f bitcoin bitcoind test_bitcoin
   -rm -f obj/*.o
   -rm -f obj/nogui/*.o
   -rm -f obj/test/*.o
   -rm -f cryptopp/obj/*.o
   -rm -f headers.h.gch

Start it and try it; but I suspect it will fail early.

On another big-endian system, it trips this assert: assert(block.hashMerkleRoot == uint256("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b")); fairly quickly.

http://endeavour.zapto.org/~me/cgminer.tar.gz ; built on 10.7.

Bitcoind is unlikely to work on your OpenBSD sparc64 system; the client does not run on big-endian systems.

To build bitcoind on DragonFly BSD (or NetBSD), you can now grab a copy of the git tree for bitcoin. From pkgsrc, you'll need to install Berkeley DB (db4); I used version 4.8, but 4.6 (also in pkgsrc, as db46) should work. You'll also need boost; I installed: boost-1.46.1, boost-libs-1.46.1, and boost-headers-1.46.

You'll need to make a few changes to makefile.unix before building:

To LIBS, I added -L/usr/pkg/lib ; replace with wherever your pkgsrc libraries are located. In LIBS, I also replaced -ldb_cxx with -ldb4_cxx.
To DEFS, I added -std=gnu++0x and -I/usr/pkg/include and -I/usr/pkg/include/db4 ; these changes don't really belong in DEFS, but its an easy place to add them.

After that, use GNU make with makefile.unix; bitcoind works and is able to download the blockchain and make transactions. This has been tested on DragonFly 2.10 / i386; the same steps should apply to NetBSD, but I haven't had a chance to try it.

Thanks!

Okay, looks like all of the patches have been merged into bitcoind!

Thanks,

>> 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.

>AFAIK the problem is not the narrowing from int to char (which is perfectly allowed if it fits). The problem is that plain "char" has undefined signedness in C (signed in most compilers these days). So values larger than >0x80 throw an overflow warning. The correct thing would be to use "unsigned char" or uint8_t.

You're right; I misunderstood the error message:

main.cpp:1773: error: narrowing conversion of '249' from 'int' to 'char' inside { }

unsigned char would be correct.

It also turns out that the SO_NOSIGPIPE issue affects NetBSD and OpenBSD, both of which don't have SO_NOSIGPIPE, but do define BSD. So none of the issues are DragonFly specific.

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.

Hi,

I have a small series of patches that allow bitcoind to build on DragonFly BSD; what would be an acceptable way to submit these patches upstream? It looks like I should make a github fork of the bitcoin/bitcoin repository, push the patches on the master branch of the clone, and submit a pull request.

Some patches are specific to DragonFly BSD; others correct minor problems that are more generic; should I submit them as one patch with one pull request? Multiple patches with one pull request? Multiple patches with multiple pull requests?

Thanks,
-- vs