Building Armory on OSX

[Red Emerald]

PPC is going to be a pain.  Sorry 

[Haplo]

I just rechecked in ./config -h for QT4 again, and it looks like it's not going to work, period. I really did not want to have to install the satoshi client >_<. Maybe if I erase my HD and start over with Linux it'll work .

Sad to say, I've been a mac user since before iPods existed, and now I would not ever buy a mac again after the retarded treatment I've gotten. Besides OpenCL, there's not a single thing new intel hardware can do that mine can't, and yet they drop all backward compatibility for OSX 10.5+? The fuck? I bet the latest linux build would compile just fine (on any hardware of my choosing, for that matter), and then I wouldn't have to jump through all these bullshit hoops just to get some random GUI kit to compile. 24 hours I'll never get back =\.

[Red Emerald]

I just rechecked in ./config -h for QT4 again, and it looks like it's not going to work, period. I really did not want to have to install the satoshi client >_<. Maybe if I erase my HD and start over with Linux it'll work .

Sad to say, I've been a mac user since before iPods existed, and now I would not ever buy a mac again after the retarded treatment I've gotten. Besides OpenCL, there's not a single thing new intel hardware can do that mine can't, and yet they drop all backward compatibility for OSX 10.5+? The fuck? I bet the latest linux build would compile just fine (on any hardware of my choosing, for that matter), and then I wouldn't have to jump through all these bullshit hoops just to get some random GUI kit to compile. 24 hours I'll never get back =\.

You need the satoshi client to get the blockchain.  So you will need either bitcoin-qt or bitcoind until the networking code is built into Armory.

Any reason you have to stick with Tiger? I'd recommend installing linux. It actually works with new software (and old hardware) and is much less of a hassle than building new software on an outdated architecture running an outdated OS.

And if you are comparing difficulties with Tiger to the latest linux build, that isn't fair at all.  I think trying to get Armory working in Ubuntu 5.04 (which was released about the same time Tiger was) would be a fair comparison and is probably just as much a PITA.

[Haplo]

Well, on the one hand I think I probably did have it figured out. Windowing agnostic mode should cause it to ignore carbon and cocoa which should fix the compatibility issues. I hope.

You need the satoshi client to get the blockchain.  So you will need either bitcoin-qt or bitcoind until the networking code is built into Armory.

I was planning on using electrum since my HD space is somewhat limited. If I can get that working I'll work on armory since the extra stuff it needs shouldn't be too hard.

Any reason you have to stick with Tiger? I'd recommend installing linux. It actually works with new software (and old hardware) and is much less of a hassle than building new software on an outdated architecture running an outdated OS.

Well, I don't like monokernels . Not that OSX is really any better, although honestly I don't know much of shit about linux . I can barely use bash ^_^. That, and I'd hardly know what to look for in terms of even basic functionality. I know Mplayer and I could probably find an IM client, but for email I'd be screwed.

And if you are comparing difficulties with Tiger to the latest linux build, that isn't fair at all.  I think trying to get Armory working in Ubuntu 5.04 (which was released about the same time Tiger was) would be a fair comparison and is probably just as much a PITA.

It'd probably be much easier and cheaper to upgrade from Ubuntu 5.04 to the latest on any hardware than to upgrade from Tiger to anything on PPC. Leopard is even more bloated than Tiger, and I'm only vaguely certain that I could upgrade that far. Even if I did even then I doubt this would be any easier since Qt doesn't support anything less than Snow Leopard. x.x

[Red Emerald]

You need the satoshi client to get the blockchain.  So you will need either bitcoin-qt or bitcoind until the networking code is built into Armory.

I was planning on using electrum since my HD space is somewhat limited. If I can get that working I'll work on armory since the extra stuff it needs shouldn't be too hard.

I don't think that electrum works like you think it does.

Any reason you have to stick with Tiger? I'd recommend installing linux. It actually works with new software (and old hardware) and is much less of a hassle than building new software on an outdated architecture running an outdated OS.

Well, I don't like monokernels . Not that OSX is really any better, although honestly I don't know much of shit about linux . I can barely use bash ^_^. That, and I'd hardly know what to look for in terms of even basic functionality. I know Mplayer and I could probably find an IM client, but for email I'd be screwed.

You haven't touched linux in a while have you? All the modern desktop distros come with all of that stuff installed.  Ubuntu is a simple install and everything is there for you.  Word processing, e-mail, web browsing, cd/dvd burning, games, irc and IM, etc., etc.  However, most modern desktop distros abandoned mainline support for PPC a while ago. Ubuntu moved PPC support to "unofficial" back at version 7, but there is a 10.04 build for PPC.

http://cdimage.ubuntu.com/xubuntu/ports/releases/10.04/release/

Compiling Armory in xubuntu 10.04 should be easy. It's new enough to have all the libraries you will need and there is a PPC build. There's even a PPA to install bitcoind and/or bitcoin-qt. Hopefully those work with the unofficial build.  Otherwise, bitcoind isn't too bad too build from source.

And if you are comparing difficulties with Tiger to the latest linux build, that isn't fair at all.  I think trying to get Armory working in Ubuntu 5.04 (which was released about the same time Tiger was) would be a fair comparison and is probably just as much a PITA.

It'd probably be much easier and cheaper to upgrade from Ubuntu 5.04 to the latest on any hardware than to upgrade from Tiger to anything on PPC. Leopard is even more bloated than Tiger, and I'm only vaguely certain that I could upgrade that far. Even if I did even then I doubt this would be any easier since Qt doesn't support anything less than Snow Leopard. x.x

I wasn't talking about the monetary cost.  I was talking about the ease of compiling the code.

[Haplo]

I don't think that electrum works like you think it does.

Last I checked electrum feeds off of full nodes with a special server interface, but isn't tied to any one server nor requires owning one.

You haven't touched linux in a while have you? All the modern desktop distros come with all of that stuff installed.  Ubuntu is a simple install and everything is there for you.  Word processing, e-mail, web browsing, cd/dvd burning, games, irc and IM, etc., etc.  However, most modern desktop distros abandoned mainline support for PPC a while ago. Ubuntu moved PPC support to "unofficial" back at version 7, but there is a 10.04 build for PPC.

http://cdimage.ubuntu.com/xubuntu/ports/releases/10.04/release/

Nifty. Is there anything in particular that I might have trouble compiling/updating? For example could I compile and run GNOME3.x on this box, or is that asking too much?

Compiling Armory in xubuntu 10.04 should be easy. It's new enough to have all the libraries you will need and there is a PPC build. There's even a PPA to install bitcoind and/or bitcoin-qt. Hopefully those work with the unofficial build.  Otherwise, bitcoind isn't too bad too build from source.

Not too worried about it, although I'm not sure what dependencies bitcoind has. Except for Qt (which tries to use newer cocoa bindings) I haven't actually had much trouble compiling things on this machine, and on linux I should probably be able to compile Qt easily enough . For ~800MB it really doesn't look bad at all.

[Red Emerald]

Well this isn't the 'Building on OSX' thread I expected, but I suppose this is still on topic.

I don't think that electrum works like you think it does.

Last I checked electrum feeds off of full nodes with a special server interface, but isn't tied to any one server nor requires owning one.

Oh sorry. I misread.  I thought you meant you either wanted to use electrum instead of bitcoin for getting the blockchain, and then still use Armory or wanted to run an electrum server which also requires bitcoind.  Those didn't make any sense, but you were saying that want to use the Electrum client.  That would work (assuming you can get it compiled )

http://cdimage.ubuntu.com/xubuntu/ports/releases/10.04/release/

Nifty. Is there anything in particular that I might have trouble compiling/updating? For example could I compile and run GNOME3.x on this box, or is that asking too much?

Well that is a link to xubuntu which uses XFCE instead of gnome.  I gave you that link to xubuntu rather than ubuntu 10.04 (which uses GNOME2 IIRC) because XFCE has lower system requirements, but still looks nice.

Compiling Armory in xubuntu 10.04 should be easy. It's new enough to have all the libraries you will need and there is a PPC build. There's even a PPA to install bitcoind and/or bitcoin-qt. Hopefully those work with the unofficial build.  Otherwise, bitcoind isn't too bad too build from source.

Not too worried about it, although I'm not sure what dependencies bitcoind has. Except for Qt (which tries to use newer cocoa bindings) I haven't actually had much trouble compiling things on this machine, and on linux I should probably be able to compile Qt easily enough . For ~800MB it really doesn't look bad at all.

Well you won't need to build bitcoin-qt, just bitcoind.  Try installing the PPA and then 'sudo apt-get install bitcoind'  That's what I did in my VirtualBox VM and it seems to work fine (Although DO NOT import that wallet since it will use 0.6's compressed keys which aren't supported by Armory's import yet).

If that fails, then the steps to compile (without UPNP) from source are pretty simple.

Code:

sudo apt-get update
sudo apt-get install -y git-core build-essential libssl-dev libboost-all-dev libdb4.8-dev libdb4.8++-dev libgtk2.0-dev

git clone https://github.com/bitcoin/bitcoin.git ~/src/bitcoin
cd ~/src/bitcoin/src

make -f makefile.unix USE_UPNP=

Good luck!

[Haplo]

Oh sorry. I misread.  I thought you meant you either wanted to use electrum instead of bitcoin for getting the blockchain, and then still use Armory or wanted to run an electrum server which also requires bitcoind.  Those didn't make any sense, but you were saying that want to use the Electrum client.  That would work (assuming you can get it compiled )

Yeah, for now I want to keep it light. My machine is about 1/100th too slow to contribute much of anything to the network . HD space is probably my biggest concern.

Well that is a link to xubuntu which uses XFCE instead of gnome.  I gave you that link to xubuntu rather than ubuntu 10.04 (which uses GNOME2 IIRC) because XFCE has lower system requirements, but still looks nice.

#$%@#%$#$%ing debian . Debian supports everything. And they have nifty net-install CD images so I can basically construct my own distro.

Well you won't need to build bitcoin-qt, just bitcoind.  Try installing the PPA and then 'sudo apt-get install bitcoind'  That's what I did in my VirtualBox VM and it seems to work fine (Although DO NOT import that wallet since it will use 0.6's compressed keys which aren't supported by Armory's import yet).

Ah, so bitcoin does use qt for its frontend. I had a suspicion . I'll have to install qt anyway for any of the clients so it's not a big deal. Since I can run the absolute latest debian (and whatever else I feel like on it) I shouldn't have to worry about compatibility issues.

[etotheipi]

So now that I got a couple emails about disgruntled mac users, I want to revive this thread to investigate how to proceed.

(1) I still have no mac system
(2) Macs are still expensive
(3) I don't know what kind of mac to get
(4) Is it possible to bundle everything, including python, into a directory and make the executable "/path/to/armory/python /path/to/armory/ArmoryQt.py"?  Or will I really need to produce real executables?

My most important question, going forward, is that I need to understand what is the most-widely-compatible system I can get that will compile code that can be used on other systems?

(5) If I get an older system, will the binaries produced be executable on newer Mac systems?  Older systems?
(6) How much variety is there in the setups?   In linux/debian, it always gets installed to /usr/share/armory.  Would mac have similar consistency?
(7) How much can I expect to pay for an acceptable, used Mac.

And please don't recommend I get a new Mac.  I'm sure the value is phenomenal.  But I really just need the cheapest thing that I can hook a monitor up to that I can use to compile and test Mac binaries.  Old mac donations would be ideal (or at least a cheap sale, I'll pay for shipping), but I don't want to commit until I know what's a good system to acquire.

[unclescrooge]

You could install Mac osx on a virtual machine.

I managed to install Snow leopard on virtualbox, using iaktos. It can't work on any hardware though, PM for the details if you want

[etotheipi]

You could install Mac osx on a virtual machine.

I managed to install Snow leopard on virtualbox, using iaktos. It can't work on any hardware though, PM for the details if you want

I have tried this no less than 3 times, and I've failed every time.  It never works for me.  If you think you can help, please email me:  etotheipi@gmail.com.  But so far, I'm convinced that real hardware is the way to go...

And on that note:  do I only need one Mac VM?  Are there multiple versions of Mac/OSX to support?

[Haplo]

Well, now that I'm on gentoo and have a real web browser I can answer that question:

Yes there are multiple versions to support. Basically it's split up between x86 and ppc, with ppc being restricted to Tiger/Leopard (which is fscking retarded considering that apple moved to LLVM....) while x86 will typically be running Snow Leopard or Lion.

The main differences are in the quartz/cocoa gui implementation, although it depends on what frontend you use. Qt4 will not build on older versions of OSX (ie anything pre-Snow Leopard) as I've found out the hard way, so if you actually intend to support them at all you'll have to use something else. I don't know how well gtk builds on older OSX (never tried), I just gave up and moved to gentoo .

I don't know that there are python bindings for cocoa, but if so it's as easy/difficult as any other gui kit, except they break backwards compatibility without having any explicit versions of the API.

[Gavin Andresen]

Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?

[etotheipi]

Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?

Does that mean that if I were to cannabilize the bitcoind code to integrate networking into Armory, that I'll never get it working on ppc?  Or does it not work, for other reasons?

Btw, have you tried Armory yet? 

P.S. -- I still don't have a working OSX VM or actual OSX-running hardware.  So I still have not been able to flesh out the Mac build/distribution process.  Sorry Mac'ers

[Haplo]

Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?

Bitcoind happens to be on the gentoo portage repository, so I checked out its dependencies to see if there was anything x86 specific. I don't see anything, so unless you guys decided to rice out your code with x86 assembler then I should be able to compile it just fine.

Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?

Does that mean that if I were to cannabilize the bitcoind code to integrate networking into Armory, that I'll never get it working on ppc?  Or does it not work, for other reasons?

Btw, have you tried Armory yet? 

P.S. -- I still don't have a working OSX VM or actual OSX-running hardware.  So I still have not been able to flesh out the Mac build/distribution process.  Sorry Mac'ers

I'll let you know. I just got my system to the point where everything is working and it does what I need it to . I think your frontend is exclusively QT, so I'll have to emerge PyQt4 and bitcoind before I can test. I'll let you know what happens.

Some other stuffs:

You can probably get an iBook or older ppc mac for cheap (if you can find one). PPC macs can't run anything greater than leopard (OSX10.5) but any program coded for Tiger or newer should run on any modern mac. New versions of the OS (in my experience) have always supported older code, but they've changed a few important things over the years so that newer code won't run on older versions. Unless you want compiz effects in armory, that shouldn't really be an issue, though . The only downside is that Tiger doesn't support garbage collection, but if you're using python to do most of your work it shouldn't be a problem. The main problem is hooking up python to the cocoa gui, which I'm pretty clueless about as I'm not a big fan of python . You'll probably want leopard since it natively supports cross development, and is the last OS to support both PPC and x86.

One more thing, how are you trying to install OSX in a VM? Apple sold their soul to microsoft in exchange for microsoft continuing to make office for mac, so Apple puts DRM controls on their OS to force it not to install on non-apple hardware (including VMs). There are some hacks around it, but I'm not up to date on any of that.

[Haplo]

Well, I got bitcoind and all the qt stuff to compile no problem, although I can't yet attest to whether it works or not.

However, I'm unable to get armory to compile. Whether I use "make swig" or "make -e swig", first I get lots of

Code:

g++ -DNDEBUG -O -g0 -native -template=no%extdef  -c ***.cpp
g++: unrecognized option '-native'
g++: unrecognized option '-template=no%extdef'

Then I get a wall of

Code:

g++: language ar not recognized

then

Code:

/usr/lib/gcc/powerpc-unknown-linux-gnu/4.5.3/../../../../lib/crt1.o:(.rodata+0x4): undefined reference to `main'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::GetValue() const':
trdlocal.cpp:(.text+0x2f4): undefined reference to `pthread_getspecific'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::SetValue(void*)':
trdlocal.cpp:(.text+0x324): undefined reference to `pthread_setspecific'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::~ThreadLocalStorage()':
trdlocal.cpp:(.text+0x430): undefined reference to `pthread_key_delete'
trdlocal.o: In function `CryptoPP::ThreadLocalStorage::ThreadLocalStorage()':
trdlocal.cpp:(.text+0x53c): undefined reference to `pthread_key_create'
collect2: ld returned 1 exit status
make[1]: *** [libcryptopp.a] Error 1
...
mv: cannot stat 'libcryptopp.a': No such file or directory
make: *** [libcryptopp.a] Error 1

However...

Code:

localhost cppForSwig # locate libcryptopp
/usr/lib/libcryptopp.a
/usr/lib/libcryptopp.so
/usr/lib/libcryptopp.so.0
/usr/lib/libcryptopp.so.0.0.0

At least some of that stuff is probably arch flag inconsistencies (gcc for ppc exclusively uses -mcpu= and not -march=, although I would have expected make -e to fix that since cflags are set globally in gentoo) but the cryptopp thing makes no sense. I have both crypto++ and pycryptopp installed. The other stuff I have no clue about.

[etotheipi]

I think there was something in the original OSX build instructions that addressed the -native and extdef stuff.  I don't remember exactly, but it's linked from the "Building Armory from Source" page.

As for libcryptopp:  I got tired of dealing with library version/compatibility issues so I switched to static compiling crypto++ right into Armory.  I needed the source code in the project anyway for Windows/MSVS, so I just did it for all versions.  Therefore, the version on your system should not matter.  But also there should be no problem compiling it, unless the crypto++ library was never compiled or tested on your architecture.

I have no idea about the "g++: language ar not recognized". 

[Haplo]

I think there was something in the original OSX build instructions that addressed the -native and extdef stuff.  I don't remember exactly, but it's linked from the "Building Armory from Source" page.

As for libcryptopp:  I got tired of dealing with library version/compatibility issues so I switched to static compiling crypto++ right into Armory.  I needed the source code in the project anyway for Windows/MSVS, so I just did it for all versions.  Therefore, the version on your system should not matter.  But also there should be no problem compiling it, unless the crypto++ library was never compiled or tested on your architecture.

I have no idea about the "g++: language ar not recognized". 

Yeah I saw the stuff about -arch in the OSX instructions. I think -arch ppc does work, but I'm not sure exactly what it does or how it relates to cflags. I'll try that and see what happens.

However, something tells me it won't work properly anyway, after reading up on the endianness disaster in the bitcoind code. Bitcoind compiles fine, but that doesn't mean it will actually work properly, and something tells me it most definitely won't. >_<

[etotheipi]

Ugh.  You just reminded me that I didn't totally understand endianness when I started the python library, and I most definitely did it wrong.  If there is a real demand for mixed-endian-arch support, I can do it.  But it may take a few days.  Up until now, I have not considered it a worthy investment of my time, because it is so fragile, something is sure to break even after I think I've fixed all of it...

[Haplo]

Ugh.  You just reminded me that I didn't totally understand endianness when I started the python library, and I most definitely did it wrong.  If there is a real demand for mixed-endian-arch support, I can do it.  But it may take a few days.  Up until now, I have not considered it a worthy investment of my time, because it is so fragile, something is sure to break even after I think I've fixed all of it...

Haha that's alright. I think I got at least electrum to work. You'd be better spending your time helping that other guy build his C implementation and do it right . I've had enough experience with endianness myself to know how inside out and backwards it makes everything, and trying to hack a fix on top of a tangled broken base implementation would be a lot of work and a lot of things that could break, and a lot more work to fix.

I'm not going to ask anyone to do something so impossibly unmaintainable. After having to compile an entire system from scratch I've gained an appreciation for having to deal with nonsense like this . Honestly I don't know how binary distros manage to do it at all.