Building Armory on OSX

[etotheipi]

There seems to be endless difficulty getting Armory compiled and running properly on Mac/OSX.  Some versions of OSX/Homebrew/Xcode seem to work fine.  Others keep putting up a fight.   I am starting a new thread, because the original Armory thread is getting diluted with OSX discussion.  I definitely want to see this discussed, but I want to reserve the Armory thread for OS-independent discussion and features, and let the OSX crowd discuss, here, how to get it working on all relevant versionsof relevant software.    

The current Build-OSX-from-source-code instructions (appears to work in Lion)
Red Emerald Discusses updates he made to the build instructions for OSX 10.7.3 and Xcode 4.0.3

I have listed a couple questions below to seed this discussion, mainly because I have never even touched an OSX machine, much less done any development on one.  I need some serious education on this!

• Most important question:  How many different binaries do I have to produce to support 95%+ of Mac users?  It sounds like I may not be able to compile just one binary... but maybe I can?
• What is the absolute most-recent version of OSX?  What versions correspond to different "generations" of Macs/OSX?  What is the earliest version I should be supporting?
• It sounds like compilation is going to be based on not only OSX version, but homebrew and xcode.  How much different is this software between versions of homebrew and xcode?  I am hoping it's just like gcc: the version doesn't really matter as long as you have it.
• Someone is offering me a Macbook with OSX 10.3.9 -- is that going to be sufficient for all development activities (for the near future, at least)?
• Anyone have fail-proof instructions for getting an OSX VM working?  I've tried three times and failed.  I'd much prefer to get VM running than get new hardware.

Btw, if you missed it in the main thread, I modified the repo so that Crypto++ is statically compiled into the _CppBlockUtils.so file.  This not only resolves a plethora of linking issues on OSX, but also Linux.  Crypto++ source was already included in the project anyway, so I might as well.  It increases build time significantly, but only the very first time you "make".

[1715680185]

1715680185

[1715680185]

1715680185

[1715680185]

1715680185

[torusJKL]

The current Build-OSX-from-source-code instructions (appears to work in Lion)

I use 10.6.8 which is Snow Leopard.
Red Emerald (second link) is using Lion (10.7.3).

[Red Emerald]

Figured I would respond to this here.

yes, consider it another donation.  Powerbook G4, OS 10.3.9.  other specs i don't recall offhand.  let me know.

Can you build universal binaries with it? Meaning PPC and Intel.

sorry, i wouldn't know.

I don't believe you can.  The Powerbooks are PowerPC, so I don't think they can compile for Intel. I'm also pretty sure that it is 32-bit.

The system I was talking about letting you borrow would be running Lion and could be setup with SSH and VNC.  If I can get a snow leopard VM up, I can get you remote access to that too.

I'll keep playing with py2app.  I'm reading through the docs and there is a "recipe" for sip but I have no idea to get it working.  I think that is the only problem left.  I'm using py2app with symlinks right now just fine.

The only problem is there are no images.  Its just a grey empty area where the logo should be.  I can submit a screenshot if you want.  It may just be a side effect of the dev py2app and so I wouldn't worry about it yet.

Also, I don't like having to replace the system links to python 2.7 with homebrew's.  I feel like that shouldn't be necessary.  I think DYLD_LIBRARY_PATH just needs to be set properly.  I'll experiment more after work.

[etotheipi]

The only problem is there are no images.  Its just a grey empty area where the logo should be.  I can submit a screenshot if you want.  It may just be a side effect of the dev py2app and so I wouldn't worry about it yet.

This is actually just a problem with the way I setup images in Armory.  They all look for the "./img/something.png" which doesn't exist unless you happen to have the executable in the same directory as the original build.  In Windows, I solved this by just copying the img directory into the "ArmoryStandalone" output directory and packaged it along with all the .dll's.  In the future, I think I will use qrcresources to try to embed all of them in a python file, I just haven't gotten around to figuring out how to use it yet.

[splatster]

I'm taking the plunge again.  I'm going to try Red Emerald's OS X Lion instructions and see where that gets me.

EDIT:
It looks like running make swig didn't compile CppBlockUtils.  I followed Red Emerald's instructions exactly (I think).  Maybe I missed a step?

Code:

ImportError: No module named CppBlockUtils

[etotheipi]

I'm taking the plunge again.  I'm going to try Red Emerald's OS X Lion instructions and see where that gets me.

EDIT:
It looks like running make swig didn't compile CppBlockUtils.  I followed Red Emerald's instructions exactly (I think).  Maybe I missed a step?

Code:

ImportError: No module named CppBlockUtils

What did "make swig" do?  It should've dumped a _CppBlockUtils.so/.dylib file into the base directory, along with CppBlockUtils.py.  If those are there, then it's probably an import error instead of a can't-find error.  Open a python shell and type "import CppBlockUtils".  It will tell you more-specifically what the error is. 

Also, make sure you've updated to the latest commit on master.  There cannot be any more issues with Crypto++, anymore.

[Red Emerald]

The only problem is there are no images.  Its just a grey empty area where the logo should be.  I can submit a screenshot if you want.  It may just be a side effect of the dev py2app and so I wouldn't worry about it yet.

This is fixed now! Thanks.

Also, I don't like having to replace the system links to python 2.7 with homebrew's.  I feel like that shouldn't be necessary.  I think DYLD_LIBRARY_PATH just needs to be set properly.  I'll experiment more after work.

I figured this out!

I added this to my .bashrc

Code:

export DYLD_LIBRARY_PATH=`brew --prefix`/lib:$DYLD_LIBRARY_PATH

and it means you don't have to change any system files (which is the whole point of brew and a good idea on a mac in general).

So the revised instructions are:

Code:

Prerequisites:
Mac OS 10.7.3
Xcode 4.0.3
Homebrew (http://mxcl.github.com/homebrew/)

Install homebrew packages:
brew update
brew install ccache # optional. make sure to set up your path for ccache by following homebrew's instructions
brew install python cryptopp swig sip qt pyqt berkeley-db

Setup environment so it can find the brew libraries instead of the system ones:
export DYLD_LIBRARY_PATH=`brew --prefix`/lib:$DYLD_LIBRARY_PATH
export BERKELEYDB_INCDIR=`brew --prefix berkeley-db`/include
export PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages:$PYTHONPATH
export CFLAGS=”-arch x86_64″
export ARCHFLAGS=”-arch x86_64″

Install twisted:
`brew --prefix`/share/python/easy_install-2.7 twisted

Install bsddb3:
`brew --prefix`/share/python/easy_install-2.7 bsddb3

Clone Armory source code:
cd ~
git clone git://github.com/etotheipi/BitcoinArmory.git
cd ~/BitcoinArmory

Make SWIG Modules
cd ~/BitcoinArmory/cppForSwig
make swig

Run Armory:
cd ~/BitcoinArmory
`brew --prefix`/bin/python ArmoryQt.py

Also, be careful that the '--' stay '--' and don't become '–'

Now I'm running a self-compiled bitcoind and the latest git head (77bbbfb) of Bitcoin Armory. I'll let you know if I find any bugs  It does seem to lock up every now and then. I'll be in the middle of filling in a description and it just hangs for a sec.  I think it might be triggered when a block is found, but it seems to happen more often than that.  It does it more than my windows system does (Actually, I haven't noticed this happening in windows). Although that system is much more powerful.

homebrew install berkeley db 5 by default (and that's what I have done).  Version 4 is also available (I grabbed it to make bitcoind happy). Does it matter if Armory uses version 5 since it is just reading the database and not writing to it?

Soon, I'll (hopefully) have instructions for bundling Armory into a ArmoryQt.app.  For now, I'm just using the symlinked build.  It's nice to just click an icon in the dock and have it open rather than running a script.

I'm thinking about writing a script to start bitcoind if it isn't already running before opening Armory.  Although this won't be needed once Armory has the networking code built in.  That day scares me a little by the way.  So much code to re-implement that bugs are inevitable.  It's nice that you can build off bitcoind for now.


EDIT: Also, I added some stuff to the .gitignore to make git happier after 'make swig' is run.  I submitted it as a pull request.

I was thinking the 'how to build from source' might be nice to have in the actual source.  Do you think that is a good idea?

[torusJKL]

I still need to create a symlink for /usr/include/python2.7.
Because the Makefile of swig checks the path and if it does not exist it will use python 2.6.

Other then that I took some of your ideas and updated my instructions:
Building Bitcoin Armory on Mac OS X 10.6.x using Homebrew

[Red Emerald]

I still need to create a symlink for /usr/include/python2.7.
Because the Makefile of swig checks the path and if it does not exist it will use python 2.6.

Other then that I took some of your ideas and updated my instructions:
Building Bitcoin Armory on Mac OS X 10.6.x using Homebrew

Lion comes with 2.7, so that must be why I don't need to do that.  It is probably better to edit the Makefile than mess with the system python.  I know bitcoin comes with multiple makefiles.  I'm just about to submit a pull request that should make the Makefile a little smarter on mac.

Are you sure you still need to set BERKELEYDB_INCDIR even with DYLD_LIBRARY_PATH set? EDIT: looks like this is still needed.  Also, `brew doctor` gives warnings about having DYLD_LIBRARY_PATH set, but I'm not sure what the proper thing to do is then.  If its a bad idea to change system files and a bad idea to change the library path, what is left to do?!  I miss compiling in linux lol

Also, my python path is way shorter than yours.  You put way more than brew says is necessary when it installs python (at least in Lion).  For me brew, says that PYTHONPATH is only needed "For non-homebrew Python"

==> Caveats
For non-homebrew Python, you need to amend your PYTHONPATH like so:
  export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH

I also noticed that when I installed qt, it installed in the time it took download.  Now instead of compiling the whole thing, brew downloads a "bottle." It really cuts down the install time.  Looks like boost does the same thing.

[Red Emerald]

Bah. I can't get easy_install-2.7 bsddb3 to work on my second system

Not sure what is going on.

Code:

$ `brew --prefix`/share/python/easy_install-2.7 bsddb3
Searching for bsddb3
Reading http://pypi.python.org/simple/bsddb3/
Reading http://www.jcea.es/programacion/pybsddb.htm
Reading http://www.argo.es/~jcea/programacion/pybsddb.htm
Best match: bsddb3 5.3.0
Downloading http://pypi.python.org/packages/source/b/bsddb3/bsddb3-5.3.0.zip#md5=305c3d42fe598b56349161497eb9bfc4
Processing bsddb3-5.3.0.zip
Running bsddb3-5.3.0/setup.py -q bdist_egg --dist-dir /var/folders/hb/00j65cb90w7ctg_k8t0sjf040000gn/T/easy_install-WXyA5J/bsddb3-5.3.0/egg-dist-tmp-h9gkqO
warning: no files found matching 'updatedb.bat'
warning: no files found matching '*.py' under directory 'bsddb3'
warning: no files found matching '*.gif' under directory 'docs'
warning: no files found matching '*.jpg' under directory 'docs'
warning: no files found matching '*.txt' under directory 'patches'
warning: no files found matching '*.patch' under directory 'patches'
warning: no files found matching '*.py' under directory 'test'
no previously-included directories found matching 'docs/build'
no previously-included directories found matching 'docs/tools/docutils'
no previously-included directories found matching 'docs/tools/sphinx'
no previously-included directories found matching 'docs/tools/pygments'
no previously-included directories found matching 'old'
no previously-included directories found matching 'test/db_home'
no previously-included directories found matching 'test/bsddb3'
In file included from /usr/local/Cellar/python/2.7.2/include/python2.7/Python.h:126,
                 from Modules/_bsddb.c:97:
/usr/local/Cellar/python/2.7.2/include/python2.7/modsupport.h:27: warning: ‘PyArg_ParseTuple’ is an unrecognized format function type
ld: library not found for -ldb
collect2: ld returned 1 exit status
error: Setup script exited with error: command '/usr/bin/llvm-gcc' failed with exit status 1

[torusJKL]

0.70-beta builds fine with my instructions on OS X 10.6.8.
I have added checkout mmap to the instructions.

[etotheipi]

0.70-beta builds fine with my instructions on OS X 10.6.8.
I have added checkout mmap to the instructions.

I wouldn't change those directions just yet.  The intention was to get 0.70-beta-alpha out there as a testing version (hence a diff branch), and when it's stable I'll merge it back into master.  So far, it sounds like it's fairly stable...

Btw, you mention having to symlink to /usr/bin/python2.7... I'm not good at all with makefiles, so I just did whatever I could that would work.   If anyone has recommendations for improvement (other than cmake), I'm open to it.  Or maybe I should just finish the cmake stuff...

[torusJKL]

Btw, you mention having to symlink to /usr/bin/python2.7... I'm not good at all with makefiles, so I just did whatever I could that would work.   If anyone has recommendations for improvement (other than cmake), I'm open to it.  Or maybe I should just finish the cmake stuff...

I'm not a Makefile expert either.
How about doing something like this

Code:

[...]
SWIG_OPTS    += -c++ -python -classic
PYTHON_PATH := $(shell which python)

ifneq (exists, $(shell [ -d PYTHON_PATH/python2.7 ]  && echo exists ))
   SWIG_INC     = -IPYTHON_PATH/python2.6
   LIBRARY_OPTS = -lpthread -lpython2.6
   ifneq (exists, $(shell [ -d PYTHON_PATH/python2.6 ]  && echo exists ))
      SWIG_INC     = -IPYTHON_PATH/python2.5
      LIBRARY_OPTS = -lpthread -lpython2.5
   endif
endif
[...]

PYTHON_PATH will contain the first path it finds.

[Red Emerald]

0.70-beta builds fine with my instructions on OS X 10.6.8.
I have added checkout mmap to the instructions.

I wouldn't change those directions just yet.  The intention was to get 0.70-beta-alpha out there as a testing version (hence a diff branch), and when it's stable I'll merge it back into master.  So far, it sounds like it's fairly stable...

Btw, you mention having to symlink to /usr/bin/python2.7... I'm not good at all with makefiles, so I just did whatever I could that would work.   If anyone has recommendations for improvement (other than cmake), I'm open to it.  Or maybe I should just finish the cmake stuff...

Using 'which python' will not work.

I made a pull request about this a few days ago.  I think cmake would be the proper way to do it though.

https://github.com/etotheipi/BitcoinArmory/pull/3

I got armory compiled on one system, but my other system is giving me trouble and I thought they were identical.  I'll likely have some updates for the Lion build instructions soon.

[etotheipi]

There was an experimental cmake system put together by "Swift Geek" for Armory.   I never got around to finishing the implementation of it.  However, I did get it integrated into the "cmake" branch on github, so all that work is sitting there, idle.  If someone wanted to check out that branch, and try to merge it into master, I might be inspired to pull it (I've been avoiding pulling in any external changes though, to avoid copyright mixing...)

Especially, if the stuff is basically plug-n-play (with some modifications to accommodate new C++ classes since 5 months ago), then I can probably do it myself.  I just don't have time to go wandering down that path right now, at least not until I know how long that path is...

[Otoh]

following & looking forward to running Armory one day on my Mac OS X (Server) Version 10.7.3 (Lion) = latest stable release

[Red Emerald]

Well I can get Armory compiled on my Lion laptop, but no luck on my workstation.

However, it uses pretty much 100% CPU always and takes awhile to do anything.  Since this is handling my money, I'd rather run Armory somewhere I know I can compile it consistently.  I'm installing it in an xubuntu 10.04 desktop VirtualBox VM right now.  Much simpler steps.

Once the blockchain finishes downloading, I'll test it out and compare CPU usage. 

[Haplo]

Ok I just spent the last !%#@#$%@#$@ 24 hours trying to compile (technically electrum, not that there's a huge difference) on my Tiger/PPC laptop. My conclusion is that it's most likely not possible, although technically not directly the fault of Armory or Electrum in particular, just that Qt is a POS that deserves never to be used ever again .

In particular, after trying to @#%$@# compile Qt like 3 times now, it has failed Error 1 and Error 2 (after an excruciatingly long config and make process), no matter which way I configure it. At first I got some unrelated problems because it didn't like being dropped in a folder with a space in the name, but even after fixing that, using -universal and -sdk it gave me the same errors I got when it screwed up for other reasons (after it failed the first time I had to completely scrap the source folder because it decided to shuffle the makefiles all kinds of wrong and then make -confclean didn't work at all either due to the pathname issue).

I might try one more time, using the "platform agnostic" version and -arch instead of -universal and -sdk, sometime after I'm done being angry. If I can just get Qt to install (fuck you nokia) then I can probably get electrum and armory running no problem.

On an unrelated note, I think homebrew is probably responsible for a lot of the inconsistencies people are seeing. I never was fond of MacPorts, and I had nothing but trouble trying to install homebrew (gave up on that). What I did find is that the python site (and others) offer up-to-date versions that install properly (and easily) and you don't have to mess with symlinks (which occur in ~/.bash_profile, at least on my box) or anything like that. Python 2.7.x works great and SIP was no problem to install. I don't expect any problems with Cryptopp, SWIG, or BDB, as everything else compiles fine, but QT is highly dependent on OS version (on mac anyway) and PyQT won't install without it.

[Red Emerald]

Ok I just spent the last !%#@#$%@#$@ 24 hours trying to compile (technically electrum, not that there's a huge difference) on my Tiger/PPC laptop. My conclusion is that it's most likely not possible, although technically not directly the fault of Armory or Electrum in particular, just that Qt is a POS that deserves never to be used ever again .

In particular, after trying to @#%$@# compile Qt like 3 times now, it has failed Error 1 and Error 2 (after an excruciatingly long config and make process), no matter which way I configure it. At first I got some unrelated problems because it didn't like being dropped in a folder with a space in the name, but even after fixing that, using -universal and -sdk it gave me the same errors I got when it screwed up for other reasons (after it failed the first time I had to completely scrap the source folder because it decided to shuffle the makefiles all kinds of wrong and then make -confclean didn't work at all either due to the pathname issue).

You should try using precompiled binaries (if they are available for an old system).

On an unrelated note, I think homebrew is probably responsible for a lot of the inconsistencies people are seeing. I never was fond of MacPorts, and I had nothing but trouble trying to install homebrew (gave up on that).

It's a one-liner to install homebrew... What problem did you have?

[Haplo]

You should try using precompiled binaries (if they are available for an old system).

They're not. I already looked. The only Qt/PyQt binaries available on Tiger are way out of date, and I know at least Electrum requires Qt4.x/PyQt4.x.

It's a one-liner to install homebrew... What problem did you have?

The fact that the PPC fork and the Tiger fork are separate. I probably screwed it up somehow, but I couldn't get it to work at all. Although homebrew seems to have installed (or something), if I type, for example
brew install cryptopp

what I get is
/usr/local/Library/Homebrew/formula.rb:554: warning: already initialized constant CHECKSUM_TYPES
/usr/local/Library/Homebrew/global.rb:80: uninitialized constant RUBY_PATCHLEVEL (NameError)
        from /usr/local/bin/brew:10:in `require'
        from /usr/local/bin/brew:10

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

[Haplo]

Well, I tried exporting CFLAGS and ARCHFLAGS, but the result was the same o.0. Oh well.

[Red Emerald]

I was able to compile in Lion.  It's a weird mix of system and brew though and I'm not sure I like it.  I don't understand what exactly is going on, but it compiles.

I'll have updated instructions up sometime soon.

EDIT: It seems like this would be a breeze if you didn't use bsddb.  It's been depreciated in python 2.6 and completely removed in 3.0.  I'm not sure if pybsddb even supports the newest version of berkeley-db4 (and berkeley-db5 has been out a while).

Looks like I had an older version in my pip cache.  I downloaded http://pypi.python.org/packages/source/b/bsddb3/bsddb3-5.3.0.tar.gz#md5=d5aa4f293c4ea755e84383537f74be82 and installed that easily.

Code:

Install homebrew packages:
$ brew install python cryptopp swig sip qt pyqt berkeley-db

$ export PATH=`brew --prefix`/share/python:$PATH
$ export CFLAGS="-arch x86_64"
$ export ARCHFLAGS="-arch x86_64"
$ export BERKELEYDB_INCDIR=`brew --prefix berkeley-db`/include
$ export BERKELEYDB_LIBDIR=`brew --prefix berkeley-db`/lib
$ export PYTHONPATH=`brew –prefix`/lib/python2.7/site-packages:$PYTHONPATH

$ pip install twisted bsddb3

$ mkdir ~/src
$ cd ~/src
$ git clone git://github.com/etotheipi/BitcoinArmory.git

$ cd BitcoinArmory/cppForSwig

This is where it gets weird.  I want this to work:

Code:

$ ln -s `brew --prefix`/lib/python2.7/config/libpython2.7.a .

But that fails with:

Code:

g++ -shared -lpthread  UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a libpython2.7.a CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
Undefined symbols for architecture x86_64:
  "_environ", referenced from:
      _initposix in libpython2.7.a(posixmodule.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [swig] Error 1

So instead I'm building against the system python v2.7.1 (even though all the modules and such are brew's v2.7.3)

Code:

$ ln -s /usr/lib/python2.7/config/libpython2.7.a .

I also had to edit the makefile

Code:

vim Makefile
================================================================================
diff --git a/cppForSwig/Makefile b/cppForSwig/Makefile
index de3bb1d..716a039 100755
--- a/cppForSwig/Makefile
+++ b/cppForSwig/Makefile
@@ -8,10 +8,10 @@ OBJS = UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUt
 
 INCLUDE_OPTS += -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS 
 LIBRARY_OPTS += -lpthread 
-SWIG_INC     += -I/usr/include/python2.7
+SWIG_INC     += -I/usr/local/include/python2.7
 SWIG_OPTS    += -c++ -python -classic
 
-ifneq (exists, $(shell [ -d /usr/include/python2.7 ]  && echo exists ))
+ifneq (exists, $(shell [ -d /usr/local/include/python2.7 ]  && echo exists ))
    SWIG_INC     = -I/usr/include/python2.6
    LIBRARY_OPTS = -lpthread 
    ifneq (exists, $(shell [ -d /usr/include/python2.6 ]  && echo exists ))
@@ -26,7 +26,7 @@ all :
        make BlockUtilsTest.out
        
 swig : $(OBJS) CppBlockUtils_wrap.o
-       g++ -shared $(LIBRARY_OPTS) $(OBJS) libpython2.6.a CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
+       g++ -shared $(LIBRARY_OPTS) $(OBJS) libpython2.7.a CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
        pyrcc4 -o ../qrc_img_resources.py ../imgList.xml
 
 BlockUtilsTest.out : $(OBJS) BlockUtilsTest.cpp
================================================================================

And then its just a little bit of waiting

Code:

make clean
make swig

cd ..
/usr/bin/python ArmoryQt.py

Note that is "/usr/bin/python" not brew's python.  I don't get it, but it works because of PYTHONPATH (I think)

Loading blockchain took 83.3 seconds

EDIT: I just clicked "Filter:" and everything locked up

[Red Emerald]

I'm compiling .82 in Lion now.

The Makefile changes made my tweaks even easier.  I just changed 2 lines and no more need for symlinks.

I use brew to install all of the dependencies (including python) and then this.  I can't get it to compile against brew's libpython2.7.a, but if you export PYTHONPATH, it can use brew's pyqt and such.

Code:

$ git diff HEAD
diff --git a/cppForSwig/Makefile b/cppForSwig/Makefile
index d5b4340..ad646bf 100755
--- a/cppForSwig/Makefile
+++ b/cppForSwig/Makefile
@@ -7,14 +7,14 @@ LINKER = g++
 OBJS = UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a
 
 
-DEPSDIR ?= /usr
+DEPSDIR ?= /usr/local
 
 INCLUDE_OPTS += -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS 
 LIBRARY_OPTS += -lpthread 
 SWIG_OPTS    += -c++ -python -classic
 PYVER           += `python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`
 SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
-STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
+STATICPYTHON +=   "/usr/lib/python2.7/config/libpython2.7.a"
 
 
 #**************************************************************************

[etotheipi]

Sorry to be a n00b, but I will use this thread for my own education.  I have never touched Mac/OSX machine in my life.   Just now, I finally got a VM setup that looks like it will work.  But I have no idea where to go...

I got git installed, from what looks like a .dmg file, which opened up in to a .pkg file which actually installed it.  Is this how OSX programs are typically packaged?  If I were to eventually create an installer/uninstaller, what would be the best target format for it?

How am I typically going to install programs and packages in OSX?  Go to website, download some file, double click?  Is there any command-line utility like apt-get for retrieving dependencies?

What is the difference between xcode and brew?  To me, it sounds like to two different flavors of build systems.  I was surprised to find see a lack of google hits for "xcode vs brew", so I suspect they are not simply flavors of the same thing.

Btw, I am running Lion, and plan to compile 64-bit binaries.  I was told that 32-bit OSX is not common at all, is that true?  Can I avoid dealing with 32-bit?  It sounds like what code I compile may not work on 10.4 (Tiger) because of Qt libraries...

Do you think it's possible that Armory could be distributed as a python script like it is in Linux?  It is "installed" by simply copying all the necessary code and binaries into /usr/share/armory, and then the shortcut is just "python /usr/share/armory/ArmoryQt.py".  I say this because I expect issues with creating a real executable out of it (like with the Mac-equiv of py2exe).

I haven't even tried the existing compilation instructions yet.  I'm currently exploring the filesystem structure and how programs work.   I just want to get some base information down about how I'm going to operating in OSX and compiling stuff.

[Red Emerald]

Sorry to be a n00b, but I will use this thread for my own education.  I have never touched Mac/OSX machine in my life.   Just now, I finally got a VM setup that looks like it will work.  But I have no idea where to go...

I got git installed, from what looks like a .dmg file, which opened up in to a .pkg file which actually installed it.  Is this how OSX programs are typically packaged?  If I were to eventually create an installer/uninstaller, what would be the best target format for it?

Usually all files are distributed in a .dmg.  Programs that install binaries and such around the system usually come as pkgs.  Standalone applications usually come as .app

http://www.tuaw.com/2007/05/02/mac-101-dmg-files-are-disk-images/
http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html

How am I typically going to install programs and packages in OSX?  Go to website, download some file, double click?

Most mac applications (that aren't in the App Store) use this workflow: go to website, download some file, double click, drag application into application folder.

Is there any command-line utility like apt-get for retrieving dependencies?

What is the difference between xcode and brew?  To me, it sounds like to two different flavors of build systems.  I was surprised to find see a lack of google hits for "xcode vs brew", so I suspect they are not simply flavors of the same thing.

brew is kind of like apt or yum.  Xcode is an editor and some command line tools.  Brew uses Xcode's command line tools for compiling.  It isn't a one vs the other kind of thing.

Btw, I am running Lion, and plan to compile 64-bit binaries.  I was told that 32-bit OSX is not common at all, is that true?  Can I avoid dealing with 32-bit?  It sounds like what code I compile may not work on 10.4 (Tiger) because of Qt libraries...

I don't have too much experience compiling distributable binaries.  10.6 and later include a 64-bit kernel.  10.7 comes with Python 2.7.  I'd be fine with just 64 bit, but I recall someone else having PPC.  Although that is probably too old to deal with binaries for.  Older systems can compile themselves (once those instructions get figured out).  I'd recommend starting with just one binary.  Then you can worry about building for multiple systems.

Do you think it's possible that Armory could be distributed as a python script like it is in Linux?  It is "installed" by simply copying all the necessary code and binaries into /usr/share/armory, and then the shortcut is just "python /usr/share/armory/ArmoryQt.py".  I say this because I expect issues with creating a real executable out of it (like with the Mac-equiv of py2exe).

I haven't even tried the existing compilation instructions yet.  I'm currently exploring the filesystem structure and how programs work.   I just want to get some base information down about how I'm going to operating in OSX and compiling stuff.

I'm sure you could get a script to work, but you should look into py2app. Pretty much all it does is compile everything into one folder and then make a shortcut.  I got it half working a couple versions ago.  I'll try again now that you compile against python differently.  You should also look at platypus.

It's not very common for apps to stick files in /usr on a Mac.  Applications usually go into /Applications.

http://sveinbjorn.org/platypus

[Red Emerald]

New and improved instructions for 64-bit Lion!

Code:

Install homebrew packages:
$ brew install python cryptopp swig sip qt pyqt berkeley-db

$ export PATH=`brew --prefix`/share/python:$PATH
$ export CFLAGS="-arch x86_64"
$ export ARCHFLAGS="-arch x86_64"
$ export BERKELEYDB_INCDIR=`brew --prefix berkeley-db`/include
$ export BERKELEYDB_LIBDIR=`brew --prefix berkeley-db`/lib

$ pip install twisted bsddb3

$ mkdir ~/src
$ cd ~/src
$ git clone git://github.com/etotheipi/BitcoinArmory.git
$ cd BitcoinArmory

Now edit the DEPSDIR and STATICPYTHON in cppForSwig/Makefile

Code:

$ git diff HEAD cppForSwig/Makefile
diff --git a/cppForSwig/Makefile b/cppForSwig/Makefile
index d5b4340..c20b9a1 100755
--- a/cppForSwig/Makefile
+++ b/cppForSwig/Makefile
@@ -7,14 +7,14 @@ LINKER = g++
 OBJS = UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a
 
 
-DEPSDIR ?= /usr
+DEPSDIR ?= /usr/local
 
 INCLUDE_OPTS += -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS 
 LIBRARY_OPTS += -lpthread 
 SWIG_OPTS    += -c++ -python -classic
 PYVER           += `python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`
 SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
-STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).a"
+STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).dylib"
 
 
 #**************************************************************************

Almost there!

Code:

$ make clean
$ make

$ python ArmoryQt.py 
********************************************************************************
Loading Armory Engine:
   Armory Version:       0.82
   PyBtcAddress Version: 1.00
   PyBtcWallet  Version: 1.35
Detected Operating system: Mac/OSX
   User home-directory   : /Users/bwstitt/Library/Application Support
   Satoshi BTC directory : /Users/bwstitt/Library/Application Support/Bitcoin/
   Armory home dir       : /Users/bwstitt/Library/Application Support/Armory/
Using settings file: /Users/bwstitt/Library/Application Support/Armory/ArmorySettings.txt
Loading wallets...
Number of wallets read in: 4
   Wallet (---------):    "Primary Cold Wallet (Watch)     "    (No Encryption)
   Wallet (---------):    "Foobar                          "    (No Encryption)
   Wallet (---------):    "Satoshi Wallet                  "    (Encrypted)
   Wallet (---------):    "Primary Hot Wallet              "    (Encrypted)
Internet connection is Available:  True
Bitcoin-Qt/bitcoind is Available:  True
Loading blockchain
Opening file 1: /Users/bwstitt/Library/Application Support/Bitcoin//blk0001.dat
Opening file 2: /Users/bwstitt/Library/Application Support/Bitcoin//blk0002.dat
Highest blkXXXX.dat file: 2
Attempting to read blockchain from file: /Users/bwstitt/Library/Application Support/Bitcoin//blk0001.dat
/Users/bwstitt/Library/Application Support/Bitcoin//blk0001.dat is 2000.04 MB
Attempting to read blockchain from file: /Users/bwstitt/Library/Application Support/Bitcoin//blk0002.dat
/Users/bwstitt/Library/Application Support/Bitcoin//blk0002.dat is 4.13251 MB
Syncing wallets with blockchain...
Syncing wallet:  ---------
Syncing wallet:  ---------
Syncing wallet:  ---------
Syncing wallet:  ---------
Loading blockchain took 123.4 seconds

Since I am using brew's libpython2.7.dylib, we don't need to set PYTHONPATH

Clicking "Filter:" still locks everything up

If you copy these instructions to your site, be careful that the backticks and quotes transfer properly.

[torusJKL]

New and improved instructions for 64-bit Lion!

Thanks Red Emerald.
The changes in the Makefile work also on Snow Leopard with Armory 0.81-alpha.

For those who get this error

Code:

$ python ArmoryQt.py 
Traceback (most recent call last):
  File "ArmoryQt.py", line 37, in <module>
    from PyQt4.QtCore import *
ImportError: dlopen(/usr/local/lib/python/PyQt4/QtCore.so, 2): Symbol not found: __cg_TIFFClientOpen
  Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /usr/local/lib/libTIFF.dylib
 in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO

Don't use the homebrew version but the one from the system

Code:

sudo rm /usr/local/lib/libtiff.dylib
sudo cp /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Resources/libTIFF.dylib /usr/local/lib/

[gweedo]

anyone know if the lion instructions work on mountain lion?

[Red Emerald]

anyone know if the lion instructions work on mountain lion?

They worked for me on both.

[gweedo]

anyone know if the lion instructions work on mountain lion?

They worked for me on both.

how did you get sip to work? I can't get it to work on mountain lion

Code:

Error: Failed executing: make install (sip.rb:41)

EDIT: Nevermind I had to update my GCC

[gweedo]

Code:

make[1]: *** [CppBlockUtils_wrap.o] Error 1
make: *** [all] Error 2

I am getting tis error on mountain lion any help?

[etotheipi]

EDIT: It seems like this would be a breeze if you didn't use bsddb.  It's been depreciated in python 2.6 and completely removed in 3.0.  I'm not sure if pybsddb even supports the newest version of berkeley-db4 (and berkeley-db5 has been out a while).

Looks like I had an older version in my pip cache.  I downloaded http://pypi.python.org/packages/source/b/bsddb3/bsddb3-5.3.0.tar.gz#md5=d5aa4f293c4ea755e84383537f74be82 and installed that easily.

Is this still an issue?  Now that I have removed the functionality for reading Satoshi wallets (because it only worked with older wallets that no one uses anymore), I can remove the bsddb depedency completely.  Would that be worth it?  I never had any interest in using bsddb myself, but obviously I have no choice if I want to read Bitcoin-Qt wallets.  However, leaving it in there would be slightly preferable in case I want to support those old wallets in the future (the new deterministic wallet formats coming at some point, will not use BSDDB).

On the topic of OSX compiling...  I have still been swamped with... life.  So I haven't had much time for development, but dabbling in OSX is a good exercise while I'm not doing other things.  So I have started learning how to compile things... why are there not packages for anything?  Is that what homebrew is for?

I got swig compiled and running without brew.  It was a good exercise.  Unnecessary complex though (downloaded pcre separately, and used the Tools/pcre-build.sh script with swig).  But from looking at instructions, it looks like I can avoid a lot of pain by just going with brew...?

[Red Emerald]

EDIT: It seems like this would be a breeze if you didn't use bsddb.  It's been depreciated in python 2.6 and completely removed in 3.0.  I'm not sure if pybsddb even supports the newest version of berkeley-db4 (and berkeley-db5 has been out a while).

Looks like I had an older version in my pip cache.  I downloaded http://pypi.python.org/packages/source/b/bsddb3/bsddb3-5.3.0.tar.gz#md5=d5aa4f293c4ea755e84383537f74be82 and installed that easily.

Is this still an issue?  Now that I have removed the functionality for reading Satoshi wallets (because it only worked with older wallets that no one uses anymore), I can remove the bsddb depedency completely.  Would that be worth it?  I never had any interest in using bsddb myself, but obviously I have no choice if I want to read Bitcoin-Qt wallets.  However, leaving it in there would be slightly preferable in case I want to support those old wallets in the future (the new deterministic wallet formats coming at some point, will not use BSDDB).

Please get rid of bsddb.

On the topic of OSX compiling...  I have still been swamped with... life.  So I haven't had much time for development, but dabbling in OSX is a good exercise while I'm not doing other things.  So I have started learning how to compile things... why are there not packages for anything?  Is that what homebrew is for?

Yes.

I got swig compiled and running without brew.  It was a good exercise.  Unnecessary complex though (downloaded pcre separately, and used the Tools/pcre-build.sh script with swig).  But from looking at instructions, it looks like I can avoid a lot of pain by just going with brew...?

Oh god.  Don't torture yourself, dude.  Manual dependency tracking is not something worth wasting your time on.  Use homebrew.  It takes all of 10 seconds to install and makes everything way easier. 

[etotheipi]

Please get rid of bsddb.

Done!  Will commit it in the next release.  I haven't really tested it, but I just commented out all the code that relies on bsddb, and it shouldn't make a difference because the only module that calls any of that code is the Satoshi-wallet import code that is disabled anyway.

I have been doing one command line call per day, between random other things.  So far, brew has been good to me.  I will try to finish the instructions you posted and maybe I'll finally have Armory working on OSX!

Anyone have advice for how I can distribute it?  The OSX equivalent of py2exe does not look... reliable.  I'll try it, but I would prefer to avoid the complexities and run it as a native python script, if possible.  Perhaps bundle up all the site-packages into the install directory so that it can be standalone without having to install extra dependencies...? 

I'm guessing that packaging and distribution will be the biggest hurdle to getting Armory released on OSX.  Perhaps someone with more OSX experience can provide guidance...

[jim618]

Hello Alan,

For the Mac OSX packaging you might want to liaise with Tachikoma, as he is working on the same thing for Electrum.

I posted on the old Electrum thread how I do it for MultiBit - some of that might be useful to you (but of course it is Java rather than python). The post is here:

https://bitcointalk.org/index.php?topic=50936.msg1075679#msg1075679

Jim

[etotheipi]

Well, I got Armory working on OSX!  I need to play around with it a little bit, but it looks like it mostly works (except for some of the text labels being cut off on the bottom... might consider some OSX-specific settings for the GUI).  I haven't actually moved any coins around with it yet, but creating wallets worked, and I was even able to change the filter (didn't freeze... though I didn't have any tx in it...)

Red Emerald:  thanks so much for the great instructions!  I did some digging around and found about 30 different copies of python and various subdirs that were all candidates for linking/include options and environment variables.  I even tried some of the others thinking I knew better than you (I wanted to try to get everything running from the same python directory tree), but nothing worked except exactly what you posted.  Thanks!

Hello Alan,

For the Mac OSX packaging you might want to liaise with Tachikoma, as he is working on the same thing for Electrum.

I posted on the old Electrum thread how I do it for MultiBit - some of that might be useful to you (but of course it is Java rather than python). The post is here:

https://bitcointalk.org/index.php?topic=50936.msg1075679#msg1075679

I'm a little bothered by the over-protectiveness of Apple (signing keys, app store reviews, etc), but I guess that's one reason many end users like them, but it really makes me not want to develop for them. 

I found a couple links for creating dmg files.  Perhaps I can copy in all the necessary site-packages directories and try to override the PYTHONPATH variable is part of running when OSX is detected.  Then it looks like I just create the .dmg and the user can expand it and drag it into the applications folder...?

http://stackoverflow.com/questions/116657/how-do-you-create-an-osx-application-dmg-from-a-python-package
http://stackoverflow.com/questions/96882/how-do-i-create-a-nice-looking-dmg-for-mac-os-x-using-command-line-tools

It looks like those two links together might give me what I need to create an automatic-dmg-creator for Armory.  I just have to experiment a bit...

[Haplo]

Anyone have advice for how I can distribute it?  The OSX equivalent of py2exe does not look... reliable.  I'll try it, but I would prefer to avoid the complexities and run it as a native python script, if possible.  Perhaps bundle up all the site-packages into the install directory so that it can be standalone without having to install extra dependencies...? 

I'm guessing that packaging and distribution will be the biggest hurdle to getting Armory released on OSX.  Perhaps someone with more OSX experience can provide guidance...

Well, you have to install brew manually on OSX, but if it's already installed it might be possible to make up a .pkg for it with a script that will install everything else required and compile/copy all the necessary parts. Not really certain how well that would work, but failing that you could just use a zip or tarball as you would in a manual installation on linux. App file bundles on OSX might also theoretically be used to contain a python script, but I don't know that the functionality is quite flexible enough for that. If you want to dissect some .app files to see how they work, right click->show contents is what you'll want to look at.

One thing that sucks on OSX though, and I'm not sure if this applies to newer versions, but filepaths which contain spaces tend to seriously mess with makefile type scripts, which cause all kinds of corruption and errors. I don't think the same applies for pkgs, but usually those are installed from a dmg which allows you to control the path name.

[etotheipi]

Anyone have advice for how I can distribute it?  The OSX equivalent of py2exe does not look... reliable.  I'll try it, but I would prefer to avoid the complexities and run it as a native python script, if possible.  Perhaps bundle up all the site-packages into the install directory so that it can be standalone without having to install extra dependencies...? 

I'm guessing that packaging and distribution will be the biggest hurdle to getting Armory released on OSX.  Perhaps someone with more OSX experience can provide guidance...

Well, you have to install brew manually on OSX, but if it's already installed it might be possible to make up a .pkg for it with a script that will install everything else required and compile/copy all the necessary parts. Not really certain how well that would work, but failing that you could just use a zip or tarball as you would in a manual installation on linux. App file bundles on OSX might also theoretically be used to contain a python script, but I don't know that the functionality is quite flexible enough for that. If you want to dissect some .app files to see how they work, right click->show contents is what you'll want to look at.

One thing that sucks on OSX though, and I'm not sure if this applies to newer versions, but filepaths which contain spaces tend to seriously mess with makefile type scripts, which cause all kinds of corruption and errors. I don't think the same applies for pkgs, but usually those are installed from a dmg which allows you to control the path name.

I definitely can't bank on the user having the stuff installed already.  It seems like it would be... "irresponsible"... to have the install script actually install brew and all the brew packages.  Perhaps there's a way to make a completely self-contained directory tree (that has python and all dependencies pre-compiled and included).  I don't see why not, it just seems like a mess.

Maybe I should try py2app... but so far I've only heard gripes about things not working right, so I imagine I won't be figuring it out, either (I'd need some serious tinkering time available). 

So, perhaps someone here could donate some time to try this.  I bet it would be even easier with:  Portable Python.

[Red Emerald]

Anyone have advice for how I can distribute it?  The OSX equivalent of py2exe does not look... reliable.  I'll try it, but I would prefer to avoid the complexities and run it as a native python script, if possible.  Perhaps bundle up all the site-packages into the install directory so that it can be standalone without having to install extra dependencies...? 

I'm guessing that packaging and distribution will be the biggest hurdle to getting Armory released on OSX.  Perhaps someone with more OSX experience can provide guidance...

Well, you have to install brew manually on OSX, but if it's already installed it might be possible to make up a .pkg for it with a script that will install everything else required and compile/copy all the necessary parts. Not really certain how well that would work, but failing that you could just use a zip or tarball as you would in a manual installation on linux. App file bundles on OSX might also theoretically be used to contain a python script, but I don't know that the functionality is quite flexible enough for that. If you want to dissect some .app files to see how they work, right click->show contents is what you'll want to look at.

One thing that sucks on OSX though, and I'm not sure if this applies to newer versions, but filepaths which contain spaces tend to seriously mess with makefile type scripts, which cause all kinds of corruption and errors. I don't think the same applies for pkgs, but usually those are installed from a dmg which allows you to control the path name.

I definitely can't bank on the user having the stuff installed already.  It seems like it would be... "irresponsible"... to have the install script actually install brew and all the brew packages.  Perhaps there's a way to make a completely self-contained directory tree (that has python and all dependencies pre-compiled and included).  I don't see why not, it just seems like a mess.

Maybe I should try py2app... but so far I've only heard gripes about things not working right, so I imagine I won't be figuring it out, either (I'd need some serious tinkering time available). 

So, perhaps someone here could donate some time to try this.  I bet it would be even easier with:  Portable Python.

I think py2app is what you should be doing.  I'll play around with it if I can get some time.

[etotheipi]

Red Emerald,

I just committed a Makefile modification to the dev branch.  It's basically just the current master with a bug fix and the updated Makefile.  Can you do a fresh checkout and confirm it works on your system, too?  Just want to make sure I did it right.  It works on the OSX VM I have.

I think py2app is what you should be doing.  I'll play around with it if I can get some time.

I will try it, too.  I just don't have high expectations.  I also had to reinstall my Win64 VM and can't get py2exe working.  I've spent hours on it and even my existing config that works on another machine isn't helping me figure it out.  Not looking forward to doing it again on OSX...

[Red Emerald]

Red Emerald,

I just committed a Makefile modification to the dev branch.  It's basically just the current master with a bug fix and the updated Makefile.  Can you do a fresh checkout and confirm it works on your system, too?  Just want to make sure I did it right.  It works on the OSX VM I have.

It works and the instructions are getting much simpler!  Once you pull out all the bsddb stuff, it should be this:

Code:

$ brew install python cryptopp swig sip qt pyqt
$ export PATH=`brew --prefix`/share/python:$PATH
$ pip install twisted
$ mkdir ~/src
$ cd ~/src
$ git clone git://github.com/etotheipi/BitcoinArmory.git
$ cd BitcoinArmory
$ make

$ PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python ArmoryQt.py

I think py2app is what you should be doing.  I'll play around with it if I can get some time.

I will try it, too.  I just don't have high expectations.  I also had to reinstall my Win64 VM and can't get py2exe working.  I've spent hours on it and even my existing config that works on another machine isn't helping me figure it out.  Not looking forward to doing it again on OSX...

I got it working no problem at all with the alias option (-A), but that isn't very helpful.  I'll try again now that you changed the makefile.

Code:

$ py2applet --make-setup ArmoryQt.py
$ vim setup.py

  set 'argv_emulation' to False

$ PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python setup.py py2app -A

$ open dist/ArmoryQt.app

EDIT: So I'm running into problems with Mountain Lion and macholib. I tried installing the development version of macholib, but that requires the development versions of altgraph and modulegraph which break the non-development version of py2app.  Hopefully you will have better luck with Lion.

This might help: http://b.atcg.us/blog/2010/04/13/py2app-hell-the-first.html

[ErebusBat]

Running into the hell of compiling Armory on OSX....

What if  you required brew for OSX?  I know that is not 'ideal' but it is loads better than what we have today.

Then users could install your custom formula and just brew install armory

https://github.com/mxcl/homebrew/wiki/Formula-Cookbook

[etotheipi]

Running into the hell of compiling Armory on OSX....

What if  you required brew for OSX?  I know that is not 'ideal' but it is loads better than what we have today.

Then users could install your custom formula and just brew install armory

https://github.com/mxcl/homebrew/wiki/Formula-Cookbook

That is a super interesting idea!

You're right, it's not ideal, but it would dramatically improve the situation -- users that really want it, can get it.  

I'm getting lost in my attempts to split blockchain loading into a background thread.  Multi-threaded programming comes with all sorts of headaches.  When I'm done with this implementation, I'll release it for testing and look at this OSX idea while the Win and Linux users beat on the new version.

EDIT: Scratch that:  I'm going to look at py2app first.  Red Emerald's link for "py2app hell" may very well help me avoid all the things I was worried about.  If that turns out to be trouble, I'll take a shot at your idea

[ErebusBat]

I am all for any solution that works.

[Red Emerald]

`brew install armoryqt` would be awesome, though a distributable binary would be better for the average user.

I'll try playing around with writing a recipe.

EDIT: wow. this is super easy.  I made a pull request to fix your makefile (it also adds qrc_img_resources.py to .gitignore since it is a generated file).  I'll post my formula in a few minutes.



https://github.com/etotheipi/BitcoinArmory/pull/18

Also, what branch should I be using? Dev still?

Here's the formula I made. It installs my dev branch which has two simple changes.  The first fixes the makefile so it can install into the brew prefix properly.  The second adds a "ArmoryQt.command" file.

You can install it by placing the below code into "`brew --prefix`/Library/Formula/bitcoinarmory.rb" and then `brew install --HEAD bitcoinarmory`

Code: ("`brew --prefix`/Library/Formula/bitcoinarmory.rb")

require 'formula'

class Bitcoinarmory < Formula
  homepage 'http://bitcoinarmory.com/'
  head 'https://github.com/WyseNynja/BitcoinArmory/tarball/dev'
  depends_on 'cryptopp'
  depends_on 'swig'
  depends_on 'sip'
  depends_on 'qt'
  depends_on 'pyqt'
  depends_on 'twisted' => :python

  def install
    ENV.j1  # if your formula's build system can't parallelize

    system "make"
    system "make DESTDIR=`brew --prefix BitcoinArmory` install"
    bin.install 'ArmoryQt.command'
  end

  def test
    system "PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python `brew --prefix bitcoinarmory`/share/armory/ArmoryQt.py -h"
  end

  def caveats; <<-EOS.undent
    BitcoinArmory.command was installed in
        #{bin}

    To symlink into ~/Applications, you can do:
        ln -s #{bin}/ArmoryQt.command ~/Applications/
    EOS
  end
end

Now you can simply open up a terminal and assuming you already have your PATH setup for brew, `ArmoryQt.command`

You can also symlink the .command file somewhere easy to double click or even drop it onto the dock.

[Red Emerald]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap homebrew/versions
brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

EDIT: I forgot to mention tapping homebrew/versions

[ErebusBat]

What version of Xcode do to have? This still fails for me, I think I might need to update.

[ErebusBat]

Grrr... mine still fails, even after an XCode upgrade.

Preprocessing...
Starting language-specific parse...
EncryptionUtils.h:178: Warning 362: operator= ignored
EncryptionUtils.h:133: Warning 402: Base class 'BinaryData' is incomplete.
BtcUtils.h:63: Warning 402: Only forward declaration 'BinaryData' was found.
BlockUtils.h:326: Warning 472: Overloaded method AddressBookEntry::AddressBookEntry(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:378: Warning 472: Overloaded method BtcAddress::BtcAddress(BinaryData) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
BlockUtils.h:414: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair &) effectively ignored,
BlockUtils.h:413: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair *).
BlockUtils.h:413: Warning 509: Overloaded method BtcAddress::addTxIO(TxIOPair *,bool) effectively ignored,
BlockUtils.h:414: Warning 509: as it is shadowed by BtcAddress::addTxIO(TxIOPair &,bool).
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BlockUtils.h:459: Warning 472: Overloaded method BtcWallet::addAddress(BinaryData) with no explicit typecheck typemap for arg 1 of type 'BinaryData'
BtcUtils.h:956: Warning 472: Overloaded method BtcUtils::verifyProofOfWork(BinaryDataRef,BinaryDataRef) with no explicit typecheck typemap for arg 0 of type 'BinaryData'
Processing types...
C++ analysis...
Generating wrappers...
g++  -I"/usr/include/python`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`" -c -O2 -pipe -fPIC  -Icryptopp -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS  -lpthread  CppBlockUtils_wrap.cxx
i686-apple-darwin11-llvm-g++-4.2: -lpthread: linker input file unused because linking not done
g++ -shared -lpthread  UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/python`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`/config/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.a" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
i686-apple-darwin11-llvm-g++-4.2: /usr/lib/python2.7/config/libpython2.7.a: No such file or directory
make[1]: *** [swig] Error 1
make: *** [all] Error 2
==> Build Environment
HOMEBREW_VERSION: 0.9.2
HEAD: 4ce8717a18bbec90cc07e07dfa296effabdc7bb4
CPU: 8-core 64-bit sandybridge
OS X: 10.7.4-x86_64
Xcode: 4.4.1 => /Developer
CLT: 1.0.0.9000000000.1.1249367152
X11: 2.6.4 in /usr/X11
CC: /usr/bin/clang
CXX: /usr/bin/clang++ => /usr/bin/clang
LD: /usr/bin/clang
CFLAGS: -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7
CXXFLAGS: -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7
LDFLAGS: -L/usr/local/lib
MACOSX_DEPLOYMENT_TARGET: 10.7
OBJC: /usr/bin/clang
PATH: /usr/local/bin:/usr/local/sbin:/Users/aburns/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/aburns/.rvm/bin:/usr/local/Library/Contributions/cmds

Error: Failed executing: make (armory-qt.rb:16)

[Red Emerald]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

thanks works great, but only thing is it never created the link to application, so I just added my own apple script

It doesn't do that part automatically. My formula tells you how to link the command after it finishes installing. You can also run "brew info wysenynja/bitcoin/armory-qt"

[ErebusBat]

Red Emerald....

I think with your forumla I have *finally* managed some form of success.... Armory appears to be loading now (loading blk0001.dat)

For others running into the dreaded error:

Code:

/usr/lib/python2.7/config/libpython2.7.a: No such file or directory

Here is what I did to, i think, finally resolve this:
 * brew uninstall anything needed  for Armory: python, cryptopp, swig, sip, qt, pyqt, twisted.
 * brew install --HEAD armory-qt  (after adding the tap of course)
 * interestingly enough this did not install python, so: brew install python

This is where things got interesting... I have somehow gotten my python into 'framework' mode so things didn't work out of the box.

Also I found that when python installs libpython is actually a relative symlink, and given that the armory build is looking in /usr/lib this is why it breaks.  I have created the following script that fixes up my symlinks for me and then a brew install armory-qt worked like a champ (i think... it build/appears to run at least).

Also the command file you built did not work for me... I had to use brew python:

Code:

python /usr/local/Cellar/armory-qt/HEAD/share/armory/ArmoryQt.py

Here is the script I made, please note this will almost certainly not work 'out of the box' but at least be a guide for others:

Code:

#!/bin/bash
# See bottom of script for example paths
CELLAR=`brew --cellar python`
FRAMEWORK_PATH="$CELLAR/2.7.3/Frameworks/Python.framework"
PYTHON_PATH="$FRAMEWORK_PATH/Versions/2.7/Python"

# Update Brew links
cd $FRAMEWORK_PATH/Versions/2.7/lib/python2.7/config
rm libpython2.7.a
rm libpython2.7.dylib
ln -s $PYTHON_PATH libpython2.7.a 
ln -s $PYTHON_PATH libpython2.7.dylib


# Now update system links
echo "Updating /usr/lib link... will need to sudo:"
sudo rm /usr/lib/python2.7
sudo ln -s $FRAMEWORK_PATH/Versions/2.7/lib/python2.7 /usr/lib/python2.7

echo "Links updated..."

# /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python
# /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

@Red Emerald: if armory does indeed come up then I will send you some coin as I have wanted this for MONTHS.  Thank you thank you thank you!

[ErebusBat]

Hrm...  So I was able to receive and send funds.  I imported a bunch of addresses (~15) and restarted... now Armory has been loading for >20 mins.....

Any ideas as to what could be causing the slowdown?

EDIT:  40 mins in and it just switched to blk0002.dat.  This sucks,  it is like using a 5 year old PC on a mac.  There has to be some reason for the slowdown.

[Red Emerald]

Red Emerald....

I think with your forumla I have *finally* managed some form of success.... Armory appears to be loading now (loading blk0001.dat)

For others running into the dreaded error:

Code:

/usr/lib/python2.7/config/libpython2.7.a: No such file or directory

Here is what I did to, i think, finally resolve this:
 * brew uninstall anything needed  for Armory: python, cryptopp, swig, sip, qt, pyqt, twisted.
 * brew install --HEAD armory-qt  (after adding the tap of course)
 * interestingly enough this did not install python, so: brew install python

This is where things got interesting... I have somehow gotten my python into 'framework' mode so things didn't work out of the box.

Also I found that when python installs libpython is actually a relative symlink, and given that the armory build is looking in /usr/lib this is why it breaks.  I have created the following script that fixes up my symlinks for me and then a brew install armory-qt worked like a champ (i think... it build/appears to run at least).

Also the command file you built did not work for me... I had to use brew python:

Code:

python /usr/local/Cellar/armory-qt/HEAD/share/armory/ArmoryQt.py

Here is the script I made, please note this will almost certainly not work 'out of the box' but at least be a guide for others:

Code:

#!/bin/bash
# See bottom of script for example paths
CELLAR=`brew --cellar python`
FRAMEWORK_PATH="$CELLAR/2.7.3/Frameworks/Python.framework"
PYTHON_PATH="$FRAMEWORK_PATH/Versions/2.7/Python"

# Update Brew links
cd $FRAMEWORK_PATH/Versions/2.7/lib/python2.7/config
rm libpython2.7.a
rm libpython2.7.dylib
ln -s $PYTHON_PATH libpython2.7.a 
ln -s $PYTHON_PATH libpython2.7.dylib


# Now update system links
echo "Updating /usr/lib link... will need to sudo:"
sudo rm /usr/lib/python2.7
sudo ln -s $FRAMEWORK_PATH/Versions/2.7/lib/python2.7 /usr/lib/python2.7

echo "Links updated..."

# /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python
# /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

@Red Emerald: if armory does indeed come up then I will send you some coin as I have wanted this for MONTHS.  Thank you thank you thank you!

My formula does not install python because brew's python isn't needed (at least in Lion+).  I built armory against the system python as that required less modifications to the Makefile.  That is also why my ArmoryQt.command uses /usr/bin/python and sets PYTHONPATH.

What version of OSX are you using?

I'm guessing your messing with the links to the Framework folders is why it won't build.  What does this command give for you?

Code:

$ ls -la /usr/lib | grep python2.7
lrwxr-xr-x    1 root     wheel    18B Jul 26 16:01 libpython.dylib@ -> libpython2.7.dylib
lrwxr-xr-x    1 root     wheel    68B Jul 26 16:01 libpython2.7.dylib@ -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/Python
lrwxr-xr-x    1 root     wheel    75B Jul 26 16:01 python2.7@ -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7

If those don't match me (likely because you have messed with those while trying to get Armory to work in the past), then change them to be what I have and try to reinstall armory-qt.  Don't point them to brew.  The system python should work fine.  

[Red Emerald]

Hrm...  So I was able to receive and send funds.  I imported a bunch of addresses (~15) and restarted... now Armory has been loading for >20 mins.....

Any ideas as to what could be causing the slowdown?

EDIT:  40 mins in and it just switched to blk0002.dat.  This sucks,  it is like using a 5 year old PC on a mac.  There has to be some reason for the slowdown.

What are your system specs? What OS version? Latest dev branch?

My load times aren't nearly that bad, but I'm on a SSD.

[ErebusBat]

My formula does not install python because brew's python isn't needed (at least in Lion+).  I built armory against the system python as that required less modifications to the Makefile.  That is also why my ArmoryQt.command uses /usr/bin/python and sets PYTHONPATH.

What version of OSX are you using?

Interesting.... I am on Lion (10.7.7).

I'm guessing your messing with the links to the Framework folders is why it won't build.

Ya probably... it was way out of whack with what you posted, here are my new 'fixed' results

Code:

$ ls -la /usr/lib | grep python2.7                                                                                                           
lrwxr-xr-x    1 root  wheel        18 Aug 22  2011 libpython.dylib -> libpython2.7.dylib
lrwxr-xr-x    1 root  wheel        68 Aug 22  2011 libpython2.7.dylib -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/Python
lrwxr-xr-x    1 root  wheel        75 Aug 28 07:57 python2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7

If those don't match me (likely because you have messed with those while trying to get Armory to work in the past), then change them to be what I have and try to reinstall armory-qt.  Don't point them to brew.  The system python should work fine.  

Expect it didn't :/  Same error I was getting before:

Code:

$ /usr/local/Cellar/armory-qt/HEAD/bin/ArmoryQt.command                                                                                      
********************************************************************************
Loading Armory Engine:
   Armory Version:       0.82.5
   PyBtcWallet  Version: 1.35
Detected Operating system: Mac/OSX
   User home-directory   : /Users/aburns/Library/Application Support
   Satoshi BTC directory : /Users/aburns/Library/Application Support/Bitcoin/
   Armory home dir       : /Users/aburns/Library/Application Support/Armory/
Fatal Python error: PyThreadState_Get: no current thread
/usr/local/Cellar/armory-qt/HEAD/bin/ArmoryQt.command: line 2: 89681 Abort trap: 6           PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python `brew --prefix wysenynja/bitcoin/armory-qt`/share/armory/ArmoryQt.py

[Red Emerald]

I saw that error on my own system, but building with the proper libpython2.7.a is what fixed it.

After fixing the symlinks, did you reinstall, or did you just try to rerun the command? You will need to uninstall and install again.

Also, what is in your site packages folder?

Code:

$ ls `brew --prefix`/lib/python2.7/site-packages
PyQt4/                                   pydot.pyc
Twisted-12.1.0-py2.7.egg-info/           pyparsing-1.5.6-py2.7.egg-info/
altgraph/                                pyparsing.py
altgraph-0.9-py2.7.egg-info/             pyparsing.pyc
bsddb3/                                  setuptools-0.6c11-py2.7.egg-info
bsddb3-5.3.0-py2.7.egg-info/             setuptools.pth
distribute-0.6.26-py2.7.egg/             sip.so@
distribute-0.6.27-py2.7.egg/             sipconfig.py@
dot_parser.py                            sipconfig.pyc
dot_parser.pyc                           sipdistutils.py@
easy-install.pth                         site.py
git_remote_helpers/                      site.pyc
git_remote_helpers-0.1.0-py2.7.egg-info@ twisted/
init_cov_core.pth                        virtualenv-1.7.1.2-py2.7.egg-info/
macholib/                                virtualenv.py
macholib-1.4.3-py2.7.egg-info/           virtualenv.pyc
modulegraph/                             virtualenv_support/
modulegraph-0.9.1-py2.7.egg-info/        virtualenvwrapper/
pip-1.1-py2.7.egg/                       virtualenvwrapper-3.4-py2.7-nspkg.pth
py2app/                                  virtualenvwrapper-3.4-py2.7.egg-info/
py2app-0.6.4-py2.7.egg-info/             zope/
pydot-1.0.28-py2.7.egg-info/             zope.interface-4.0.1-py2.7-nspkg.pth
pydot.py                                 zope.interface-4.0.1-py2.7.egg-info/

I have a few more things than you probably, but yours should look similar to mine.

[ErebusBat]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

Just tried to get an updated version of bitcoind from your forumula and got this error:

Code:

$ brew install bitcoind                                                                                                                  
Error: No available formula for berkeley-db4 (dependency of bitcoind)

Did you do a keg for that from somewhere?

[etotheipi]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

Just tried to get an updated version of bitcoind from your forumula and got this error:

Code:

$ brew install bitcoind                                                                                                                  
Error: No available formula for berkeley-db4 (dependency of bitcoind)

Did you do a keg for that from somewhere?

Btw, I finally removed bsddb, so that dependency should be gone...

Though, in the future, I might add it back if the devs don't move on this new wallet format.  Luckily, I am pretty sure they won't be using BSDDB for the new wallet format, but if they procrastinate much longer past when I get compressed public keys, I might have to do this.

[ErebusBat]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

Just tried to get an updated version of bitcoind from your forumula and got this error:

Code:

$ brew install bitcoind                                                                                                                  
Error: No available formula for berkeley-db4 (dependency of bitcoind)

Did you do a keg for that from somewhere?

Btw, I finally removed bsddb, so that dependency should be gone...

Though, in the future, I might add it back if the devs don't move on this new wallet format.  Luckily, I am pretty sure they won't be using BSDDB for the new wallet format, but if they procrastinate much longer past when I get compressed public keys, I might have to do this.

But this is for bitcoind.... doesn't that still depend on BDB?

[Red Emerald]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

Just tried to get an updated version of bitcoind from your forumula and got this error:

Code:

$ brew install bitcoind                                                                                                                  
Error: No available formula for berkeley-db4 (dependency of bitcoind)

Did you do a keg for that from somewhere?

Btw, I finally removed bsddb, so that dependency should be gone...

Though, in the future, I might add it back if the devs don't move on this new wallet format.  Luckily, I am pretty sure they won't be using BSDDB for the new wallet format, but if they procrastinate much longer past when I get compressed public keys, I might have to do this.

But this is for bitcoind.... doesn't that still depend on BDB?

It's in https://github.com/Homebrew/homebrew-versions

Code:

brew tap homebrew/versions
brew install wysenynja/bitcoin/bitcoind

[ErebusBat]

Red Emerald, amazing formula but how do I upgrade, armory is saying their is a new version but

Code:

% brew upgrade wysenynja/bitcoin/armory-qt
Error: armory-qt-HEAD already installed
% brew upgrade --HEAD wysenynja/bitcoin/armory-qt
Error: armory-qt-HEAD already installed

You can't until he updates the forumla.  Last I knew he was waiting for mac specific things to be merged into master.

[ErebusBat]

It's in https://github.com/Homebrew/homebrew-versions

Code:

brew tap homebrew/versions
brew install wysenynja/bitcoin/bitcoind

Thanks... I added it but now I am getting a compile error for it (berkeley-db4):

Code:

libtool: compile:  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -I. -I../dist/.. -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.8 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -fno-strict-aliasing ../dist/../libdb_java/db_java_wrap.c  -fno-common -DPIC -o .libs/db_java_wrap.o
../dist/../libdb_java/db_java_wrap.c:137:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^
1 error generated.

I have my feelings that it is due to upgrading to Mt. Lion this weekend, has anyone else compiled this on Mt. Lion?

[Red Emerald]

It's in https://github.com/Homebrew/homebrew-versions

Code:

brew tap homebrew/versions
brew install wysenynja/bitcoin/bitcoind

Thanks... I added it but now I am getting a compile error for it (berkeley-db4):

Code:

libtool: compile:  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -I. -I../dist/.. -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.8 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -fno-strict-aliasing ../dist/../libdb_java/db_java_wrap.c  -fno-common -DPIC -o .libs/db_java_wrap.o
../dist/../libdb_java/db_java_wrap.c:137:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^
1 error generated.

I have my feelings that it is due to upgrading to Mt. Lion this weekend, has anyone else compiled this on Mt. Lion?

The new version thing is a bug.  I am waiting for etotheipi to merge some changes and then I will switch the formula to his repo.

You probably need to update your command line tools.  Open up Xcode > Preferences > Downloads.  I've compiled on Mountain Lion.  Also, maybe run `brew doctor` and see if it says anything.

[picobit]

Hrm...  So I was able to receive and send funds.  I imported a bunch of addresses (~15) and restarted... now Armory has been loading for >20 mins.....

Any ideas as to what could be causing the slowdown?

EDIT:  40 mins in and it just switched to blk0002.dat.  This sucks,  it is like using a 5 year old PC on a mac.  There has to be some reason for the slowdown.

What are your system specs? What OS version? Latest dev branch?

My load times aren't nearly that bad, but I'm on a SSD.

This is not right.  On my mac it takes less than 2 min to load.  I am using an SSD too, but it is CPU limited.

However, it may be a crash.  Occationally, I see Armory crash when reading a block, in particular if I start it while the Satoshi client is catching up.  I guess it gets confused by reading a block while it is being written to disk.  That could in principle also hang your client.

[ErebusBat]

You probably need to update your command line tools.  Open up Xcode > Preferences > Downloads.  I've compiled on Mountain Lion.  Also, maybe run `brew doctor` and see if it says anything.

Yup that was it... I didn't realize that the OS upgrade would un-install them.

Thanks for everything Red Emerald

[Red Emerald]

You probably need to update your command line tools.  Open up Xcode > Preferences > Downloads.  I've compiled on Mountain Lion.  Also, maybe run `brew doctor` and see if it says anything.

Yup that was it... I didn't realize that the OS upgrade would un-install them.

Thanks for everything Red Emerald

Well it leaves them installed, but I think they are all compiled for Lion which has older versions of a lot of things and so won't work.

Glad I could help!

[Red Emerald]

I'm testing the threaded branch on my own machine.  It built without issue for me and is easy to run with "PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python ArmoryQt.py"

Once I'm happy with the stability, I'll switch my brew tap to it.

If you are itching to try out the bleeding edge: https://github.com/WyseNynja/BitcoinArmory/tree/threading

[simonk83]

Hi guys,

So, this might be an interesting test for you.   I have just (literally, today) moved from Windows to OSX.   I'm almost totally new to Mac's in general, but certainly new to compiling on it.

I do have xcode and the command line tools installed, but not homebrew or anything else just yet.

Does anyone fancy giving me a bit of a step by step guide for getting Armory up and running?   I figure it'll serve as a good beginners guide going forward, and will also be a good test of the processes you've set up.

Much appreciated!!

[picobit]

I installed the new "threading" version of Armory under Mac OS X Mountain Lion.  Although still slightly experimental, it is the version that etotheipi says is going to be the official version real soon now, when Armory goes into beta (from alpha, see https://bitcointalk.org/index.php?topic=56424.msg1315445#msg1315445).

I use homebrew to install the dependencies.  On a Mac, there are at least three competing package managers for Unix/Linux software, homebrew, macports and fink.  I would be seriously surprised if it matters which one you choose, so don't let this thread decide for you.  Also, I have chosen to use the system's Python installation, and *not* install homebrews own python.  This is more in line with homebrew's philosophy of not duplicating packages, and is one of the reasons I chose homebrew.  But again, I really cannot claim superiority of this approach [in fact, I really don't know what I am doing ], and I am sure both choices are equally good for Armory.

So here are the steps (partly from memory, forgive me if I forgot something essential!).  All of this is done in a Terminal window.

0) Be sure to have the newest xcode installed, including the command line tools.

1) Install homebrew by copy-pasting the ruby installation command from the homebrew web page into the Terminal, see http://mxcl.github.com/homebrew/    

1a) You probably want to run brew doctor and fix any fixable problems before proceeding.

2) Install the first batch of prerequisites for Armory

Code:

brew install cryptopp
brew install swig
brew install sip
brew install qt
brew install pyqt
brew install berkeley-db

2a) (EDIT)  You have now installed Python stuff in /usr/local/lib.  The standard OS X Python will not find them, unless you add the directory to PYTHONPATH, e.g. by adding this line to the .profile file in your home directory

Code:

export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH

Note that the .profile file starts with a period, meaning that it is a hidden file.

3) You also need some Python packages not in homebrew.  These can be installed with Python's easy_install or with pip (easy_install pip).  I think pip makes it easier to uninstall later, but neither of them do a proper job when it comes to package management

Code:

easy_install twisted
export BERKELEYDB_INCDIR=/usr/local/Cellar/berkeley-db/5.3.21/include
easy_install bsddb3

WARNING: Don't uncritically copy-past the BERKELEYDB_INCDIR path above, it will change as new versions come along.  Instead, type it using TAB-completion.

4) Get the Armory source code, and switch to the threading branch (this assumes you want it placed as a subdirectory under your home directory, replace the first cd command if you want it elsewhere).

Code:

cd ~
git clone git://github.com/etotheipi/BitcoinArmory.git
cd BitcoinArmory
git checkout threading

(I am no git wizard - this could undoubtedly be done as one git command.)

5) Compile the C++/swig part of Armory.

Code:

cd cppForSwig
export CFLAGS=”-arch x86_64″
export ARCHFLAGS=”-arch x86_64″
make swig

6) Return to the main Armory directory

Code:

cd ..

7) Try it out!  Make sure you have internet, that the Satoshi client is running and (preferably) that it has finished catching up.

Code:

python ArmoryQt.py

8 ) Have fun.  Although I do have a bitcoin address in my signature, I really think you should donate to the Armory guys instead!

[etotheipi]

Thanks for that picobit.

While I don't know much about OSX, I do want to point out that I removed the BSDDB dependency in Armory.  So the steps that involve configuring and installing that can be removed.  It was because the BSDDB was only used for migrating pre-0.6.0 Bitcoin-Qt wallets, and those have been "out of style" so long that I finally removed the feature altogether.

Maybe it's okay to leave those steps, since I might add it back in one day.  But if someone is getting stuck there, they should know that it's unimportant.

[Red Emerald]

picobit, are you also setting PYTHONPATH?

Otherwise, I don't see how the system python would find pyqt.

[simonk83]

Ah, forgot about this, giving it a try now and I get the following:

macmini:~ Simon$ export BERKELEYDB_INCDIR=/usr/local/Cellar/berkeley-db/5.3.21/include/
macmini:~ Simon$ sudo easy_install bsddb3
Searching for bsddb3
Reading http://pypi.python.org/simple/bsddb3/
Reading http://www.jcea.es/programacion/pybsddb.htm
Reading http://www.argo.es/~jcea/programacion/pybsddb.htm
Best match: bsddb3 5.3.0
Downloading http://pypi.python.org/packages/source/b/bsddb3/bsddb3-5.3.0.zip#md5=305c3d42fe598b56349161497eb9bfc4
Processing bsddb3-5.3.0.zip
Running bsddb3-5.3.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Dm3no_/bsddb3-5.3.0/egg-dist-tmp-VrGGt6
Can't find a local Berkeley DB installation.
(suggestion: try the --berkeley-db=/path/to/bsddb option)
error: Setup script exited with 1
macmini:~ Simon$

Everything up until then went OK, and I assume it's a simple fix but I just don't know enough unix/OSX to troubleshoot it unfortunately...


EDIT:  OK, somehow managed to get BerkeleyDB installed and got past that error.   Moving on

[simonk83]

Right, now stuck on:

macmini:BitcoinArmory Simon$ cd cppForSwig
macmini:cppForSwig Simon$ export CFLAGS=”-arch x86_64″
-bash: export: `x86_64″': not a valid identifier


EDIT:  Ok, think I sorted that, just something wrong with the speech marks  

[simonk83]

Right, when running the "make swig" command, it processes for while then ends with:

swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
make: swig: No such file or directory
make: *** [CppBlockUtils_wrap.cxx] Error 1

[picobit]

Right, when running the "make swig" command, it processes for while then ends with:

swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
make: swig: No such file or directory
make: *** [CppBlockUtils_wrap.cxx] Error 1

Is swig in /usr/local/bin?  If so, you probably just need to add /usr/local/bin to the PATH

picobit, are you also setting PYTHONPATH?

Otherwise, I don't see how the system python would find pyqt.

Yes indeed, I set PYTHONPATH.  I will edit my post and add it.

[simonk83]

Right, when running the "make swig" command, it processes for while then ends with:

swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
make: swig: No such file or directory
make: *** [CppBlockUtils_wrap.cxx] Error 1

Is swig in /usr/local/bin?  If so, you probably just need to add /usr/local/bin to the PATH

No, swig isn't present....

[Red Emerald]

Right, when running the "make swig" command, it processes for while then ends with:

swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
make: swig: No such file or directory
make: *** [CppBlockUtils_wrap.cxx] Error 1

Is swig in /usr/local/bin?  If so, you probably just need to add /usr/local/bin to the PATH

No, swig isn't present....

Code:

brew install swig

[simonk83]

Right, when running the "make swig" command, it processes for while then ends with:

swig -c++ -python -classic -threads -outdir ../ -v CppBlockUtils.i
make: swig: No such file or directory
make: *** [CppBlockUtils_wrap.cxx] Error 1

Is swig in /usr/local/bin?  If so, you probably just need to add /usr/local/bin to the PATH

No, swig isn't present....

Code:

brew install swig

Thanks

Well, I did that and swig installed fine as far as I can tell.  However, make swig gives me:

Code:

macmini:cppforswig Simon$ make swig
g++ -shared -lpthread  UniversalTimer.o BinaryData.o FileDataPtr.o BtcUtils.o BlockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/python`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`/config/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.a" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
pyrcc4 -o ../qrc_img_resources.py ../imgList.xml
make: pyrcc4: No such file or directory
make: *** [swig] Error 1

brew install pyrcc4? (edit:  nope...)


EDIT2:  Ah, hold on.  The initial round of "brew installs" didn't work I don't think (hence why I didn't have swig).   Just reinstalling the stuff now.

[simonk83]

Success gentlemen

The only thing that needs adding to those instructions is:

Code:

brew install berkeley-db

The rest was me not installing the stuff properly (I grabbed the entire block and pasted it into the terminal.  I though it was installing the stuff 1 by 1 but clearly not ).

Thanks a lot for the help everyone.   Not ideal having to install it this way, but it works (and it's kind of fun if you're a dork like me, so that helps).

[Red Emerald]

EDIT: Check out the most up-to-date instructions here.

Success gentlemen

The only thing that needs adding to those instructions is:

Code:

brew install berkeley-db

The rest was me not installing the stuff properly (I grabbed the entire block and pasted it into the terminal.  I though it was installing the stuff 1 by 1 but clearly not ).

Thanks a lot for the help everyone.   Not ideal having to install it this way, but it works (and it's kind of fun if you're a dork like me, so that helps).

We don't need berkeley-db anymore.  It was only used to import the satoshi wallets and that has been dropped.


Here are my steps:

Code:

$ brew doctor

Do what the doctor says!

Code:

$ brew install python cryptopp swig sip qt pyqt

Make sure this ends in success!

I prefer to use brew's python since it is newer (2.7.3 vs ML's 2.7.2). Plus it is installed as my user so I can muck with it without sudo and I don't have to worry about breaking anything on my system.

Put this in your ~/.bashrc.  I do not recommend setting PYTHONPATH here.  It can get annoying when you are working on other Python projects.

Code:

export PATH=`brew --prefix`/share/python:$PATH
export CFLAGS="-arch x86_64"
export ARCHFLAGS="-arch x86_64"

Then run some more commands

Code:

$ pip install twisted
$ mkdir ~/src
$ cd ~/src
$ git clone git://github.com/etotheipi/BitcoinArmory.git
$ git checkout threading
$ cd BitcoinArmory
$ make

Hopefully soon we will won't need the threading branch and can just use master.

Running Armory is a bit awkward, but it isn't too bad.  You have to set PYTHONPATH so the system python can find pyqt and twisted.  I'm not sure why, but I haven't been able to get it built against brew's python.  Since "make" builds against the system python, you need to make sure you don't use some other one. Brew recommends you put it's python in the front of PATH, so using the full path to the system python makes sure we use the right one.

Code:

$ PYTHONPATH=`brew --prefix`/lib/python2.7/site-packages /usr/bin/python ArmoryQt.py

Once I can get it Armory online properly, I'll update my brew tap.  I keep getting a segfault while it's loading the blockchain.  I'm re-downloading the chain now.

EDIT: A fresh blockchain didn't help.  I'm going to dig deeper this weekend.

[Red Emerald]

So I made this super simple for people.  I'm sure etotheipi will eventually do this himself, but if you want Armory up and running fast and right now.

Code:

brew tap homebrew/versions
brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/bitcoind
brew install --HEAD wysenynja/bitcoin/armory-qt

You don't need to install bitcoind, but I like to. I might eventually add a startup service for bitcoind.

EDIT: I forgot to mention tapping homebrew/versions

berkely-db4 is now in the main brew formula list.  However, armory doesn't need it anymore. Once threading gets merged into master, I'll update this tap.  I'll also get rid of the "--HEAD" requirement

[Red Emerald]

I've updated my brew tap to point to master! Let me know if it works!

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install --HEAD wysenynja/bitcoin/armory-qt

From there it's incredibly easy to run (assuming you have brew's bin on your path, which you probably do).

Code:

ArmoryQt.command

If you need bitcoind, it is in my tap, too.

Code:

brew install wysenynja/bitcoin/bitcoind

Once etotheipi tags a stable version, I'll setup the formula so you don't have to use "--HEAD"

[etotheipi]

I've updated my brew tap to point to master! Let me know if it works!

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install --HEAD wysenynja/bitcoin/armory-qt

From there it's incredibly easy to run (assuming you have brew's bin on your path, which you probably do).

Code:

ArmoryQt.command

If you need bitcoind, it is in my tap, too.

Code:

brew install wysenynja/bitcoin/bitcoind

Once etotheipi tags a stable version, I'll setup the formula so you don't have to use "--HEAD"

There's already a tag for "v0.85-beta".  Though I accidentally tagged it on the threading branch, I don't think that matters.  Simply referencing that tag should get you there, regardless of what branch you're on.

[Red Emerald]

I've updated my brew tap to point to master! Let me know if it works!

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install --HEAD wysenynja/bitcoin/armory-qt

From there it's incredibly easy to run (assuming you have brew's bin on your path, which you probably do).

Code:

ArmoryQt.command

If you need bitcoind, it is in my tap, too.

Code:

brew install wysenynja/bitcoin/bitcoind

Once etotheipi tags a stable version, I'll setup the formula so you don't have to use "--HEAD"

There's already a tag for "v0.85-beta".  Though I accidentally tagged it on the threading branch, I don't think that matters.  Simply referencing that tag should get you there, regardless of what branch you're on.

Done!

You should probably update the instructions on bitcoinarmory.com to match.

I'll keep "--HEAD" on whatever branch you are developing and make the default install your most recent stable tag/branch.

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew update
brew install wysenynja/bitcoin/armory-qt
ArmoryQt.command

[gweedo]

It gives me the error, that it is up to date and it isn't armory is still 0.8.2.5 BETA

[Red Emerald]

It gives me the error, that it is up to date and it isn't armory is still 0.8.4

Can you post the output of `brew install wysenynja/bitcoin/armory-qt`

Also, if you have already used my tap, you will need to `brew update` otherwise you will be using the old formula.

[gweedo]

I did brew update and it did list it as one of the forumlas it did update

Code:

% brew install wysenynja/bitcoin/armory-qt
Error: armory-qt-HEAD already installed

[Red Emerald]

I did brew update and it did list it as one of the forumlas it did update

Code:

% brew install wysenynja/bitcoin/armory-qt
Error: armory-qt-HEAD already installed

Looks like you need to uninstall the version you have.  It considers a "HEAD" version the newest no matter what.  Run this and then retry.

Code:

brew uninstall armory-qt

You don't need the "wysenynja/bitcoin/" part when uninstalling for some reason (although it doesn't hurt).

EDIT: Oh yeah. and `brew update` again. i just set the version number explicitly in the formula. It was autodetecting just "beta" before.

[gweedo]

ok that worked and just for anyone else it did keep my wallets in tack after I uninstalled and reinstalled, even thou I still backed them up before the process

[etotheipi]

I've updated my brew tap to point to master! Let me know if it works!

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install --HEAD wysenynja/bitcoin/armory-qt

From there it's incredibly easy to run (assuming you have brew's bin on your path, which you probably do).

Code:

ArmoryQt.command

If you need bitcoind, it is in my tap, too.

Code:

brew install wysenynja/bitcoin/bitcoind

Once etotheipi tags a stable version, I'll setup the formula so you don't have to use "--HEAD"

There's already a tag for "v0.85-beta".  Though I accidentally tagged it on the threading branch, I don't think that matters.  Simply referencing that tag should get you there, regardless of what branch you're on.

Done!

You should probably update the instructions on bitcoinarmory.com to match.

I'll keep "--HEAD" on whatever branch you are developing and make the default install your most recent stable tag/branch.

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/armory-qt
ArmoryQt.command

Master branch is the correct place for it.  That's intended to house only the most stable releases.  All other intermediate and feature-testing versions will always be on a branch.  It just might be worth documenting how to modify it if the user wishes to switch to a different branch.

Also, I'm not sure what needs modifying in the instructions...?  HEAD on Master is actually identical to v0.85-beta, I just happened to tag it before I did the merge threading->master but after I merged master->threading (so they are the same).

[Red Emerald]

I've updated my brew tap to point to master! Let me know if it works!

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install --HEAD wysenynja/bitcoin/armory-qt

From there it's incredibly easy to run (assuming you have brew's bin on your path, which you probably do).

Code:

ArmoryQt.command

If you need bitcoind, it is in my tap, too.

Code:

brew install wysenynja/bitcoin/bitcoind

Once etotheipi tags a stable version, I'll setup the formula so you don't have to use "--HEAD"

There's already a tag for "v0.85-beta".  Though I accidentally tagged it on the threading branch, I don't think that matters.  Simply referencing that tag should get you there, regardless of what branch you're on.

Done!

You should probably update the instructions on bitcoinarmory.com to match.

I'll keep "--HEAD" on whatever branch you are developing and make the default install your most recent stable tag/branch.

Code:

brew doctor
brew tap WyseNynja/bitcoin
brew install wysenynja/bitcoin/armory-qt
ArmoryQt.command

Master branch is the correct place for it.  That's intended to house only the most stable releases.  All other intermediate and feature-testing versions will always be on a branch.  It just might be worth documenting how to modify it if the user wishes to switch to a different branch.

If someone wants to build a weird branch, they should just git clone it and make it themselves.  No need for the brew tap to handle those cases.

Also, I'm not sure what needs modifying in the instructions...?  HEAD on Master is actually identical to v0.85-beta, I just happened to tag it before I did the merge threading->master but after I merged master->threading (so they are the same).

The instructions you have posted on your website under "User “Red Emerald” provided the following variant for Mac OSX 10.7.3 with Xcode 4.0.3."  are from Lion and involve making symlinks and such which since then I've decided are a bad idea and they also still reference berkeley-db.

I posted updated instructions that work on Mountain Lion and probably Lion and anywhere else brew runs.  These should definitely replace the Lion instructions you have from me.  The segfault I mention is that broken wallet I sent you that I still haven't had time to dig into.

[Red Emerald]

ok that worked and just for anyone else it did keep my wallets in tack after I uninstalled and reinstalled, even thou I still backed them up before the process

The wallets and other user-specific files are kept in a folder in ~/Library/Application Support/Armory IIRC.  Brew installs the program to /usr/local/Cellar, so there is no risk of losing any of your data.

Good thing to mention though.

[etotheipi]

The instructions you have posted on your website under "User “Red Emerald” provided the following variant for Mac OSX 10.7.3 with Xcode 4.0.3."  are from Lion and involve making symlinks and such which since then I've decided are a bad idea and they also still reference berkeley-db.

I posted updated instructions that work on Mountain Lion and probably Lion and anywhere else brew runs.  These should definitely replace the Lion instructions you have from me.  The segfault I mention is that broken wallet I sent you that I still haven't had time to dig into.

Oh, I forgot about the building-from-source page, there.  I updated the "Get Armory" page to link to one of your posts, but that should be updated as well.  I'm wondering if there is a more auto-up-to-date way we can have your solution linked from that page.

Also, I should investigate if there's a way for me to "approve" of a particular version of your build scripts.  Perhaps, a "formula" that I can manually verify is getting the code from github, and compiling everything from brew, and then put my GPG signature on it.  Not that I don't trust you, but I'm sure that you understand I don't want to sign a script that has an arbitrary download link on it that could be swapped out from under me/you/us (besides github links).

Or maybe you could help figure out a way to bundle it in a more-convenient way.  It's a lot easier for me to verify a solution, than it is to come up with it from scratch...

[Red Emerald]

The instructions you have posted on your website under "User “Red Emerald” provided the following variant for Mac OSX 10.7.3 with Xcode 4.0.3."  are from Lion and involve making symlinks and such which since then I've decided are a bad idea and they also still reference berkeley-db.

I posted updated instructions that work on Mountain Lion and probably Lion and anywhere else brew runs.  These should definitely replace the Lion instructions you have from me.  The segfault I mention is that broken wallet I sent you that I still haven't had time to dig into.

Oh, I forgot about the building-from-source page, there.  I updated the "Get Armory" page to link to one of your posts, but that should be updated as well.  I'm wondering if there is a more auto-up-to-date way we can have your solution linked from that page.

Also, I should investigate if there's a way for me to "approve" of a particular version of your build scripts.  Perhaps, a "formula" that I can manually verify is getting the code from github, and compiling everything from brew, and then put my GPG signature on it.  Not that I don't trust you, but I'm sure that you understand I don't want to sign a script that has an arbitrary download link on it that could be swapped out from under me/you/us (besides github links).

Or maybe you could help figure out a way to bundle it in a more-convenient way.  It's a lot easier for me to verify a solution, than it is to come up with it from scratch...

If you `brew cat wysenynja/bitcoin/armory-qt` you can see what the (very short) formula does.  It even has the hash of the tar.gz from github in it so if someone changes the link, brew will give an error.

If you `brew fetch wysenynja/bitcoin/armory-qt` it will output the url and the hashes for the downloaded file without installing it.

You could also fork my bitcoin tap and use git to sign those release commits.

[etotheipi]

The instructions you have posted on your website under "User “Red Emerald” provided the following variant for Mac OSX 10.7.3 with Xcode 4.0.3."  are from Lion and involve making symlinks and such which since then I've decided are a bad idea and they also still reference berkeley-db.

I posted updated instructions that work on Mountain Lion and probably Lion and anywhere else brew runs.  These should definitely replace the Lion instructions you have from me.  The segfault I mention is that broken wallet I sent you that I still haven't had time to dig into.

Oh, I forgot about the building-from-source page, there.  I updated the "Get Armory" page to link to one of your posts, but that should be updated as well.  I'm wondering if there is a more auto-up-to-date way we can have your solution linked from that page.

Also, I should investigate if there's a way for me to "approve" of a particular version of your build scripts.  Perhaps, a "formula" that I can manually verify is getting the code from github, and compiling everything from brew, and then put my GPG signature on it.  Not that I don't trust you, but I'm sure that you understand I don't want to sign a script that has an arbitrary download link on it that could be swapped out from under me/you/us (besides github links).

Or maybe you could help figure out a way to bundle it in a more-convenient way.  It's a lot easier for me to verify a solution, than it is to come up with it from scratch...

If you `brew cat wysenynja/bitcoin/armory-qt` you can see what the (very short) formula does.  It even has the hash of the tar.gz from github in it so if someone changes the link, brew will give an error.

If you `brew fetch wysenynja/bitcoin/armory-qt` it will output the url and the hashes for the downloaded file without installing it.

You could also fork my bitcoin tap and use git to sign those release commits.

Do you think it would be [reasonably] possible to create a .dmg with all the dependencies?  Or is it a s***load of code/binaries to bundle?  It sounds like the script that goes and picks up the dependencies from brew is ideal, efficiency-wise, but does leave open subtle attack vectors (poisoning brew modules?).  I don't know ... I really want to support OSX users, but I have so little OSX experience...

[Red Emerald]

The instructions you have posted on your website under "User “Red Emerald” provided the following variant for Mac OSX 10.7.3 with Xcode 4.0.3."  are from Lion and involve making symlinks and such which since then I've decided are a bad idea and they also still reference berkeley-db.

I posted updated instructions that work on Mountain Lion and probably Lion and anywhere else brew runs.  These should definitely replace the Lion instructions you have from me.  The segfault I mention is that broken wallet I sent you that I still haven't had time to dig into.

Oh, I forgot about the building-from-source page, there.  I updated the "Get Armory" page to link to one of your posts, but that should be updated as well.  I'm wondering if there is a more auto-up-to-date way we can have your solution linked from that page.

Also, I should investigate if there's a way for me to "approve" of a particular version of your build scripts.  Perhaps, a "formula" that I can manually verify is getting the code from github, and compiling everything from brew, and then put my GPG signature on it.  Not that I don't trust you, but I'm sure that you understand I don't want to sign a script that has an arbitrary download link on it that could be swapped out from under me/you/us (besides github links).

Or maybe you could help figure out a way to bundle it in a more-convenient way.  It's a lot easier for me to verify a solution, than it is to come up with it from scratch...

If you `brew cat wysenynja/bitcoin/armory-qt` you can see what the (very short) formula does.  It even has the hash of the tar.gz from github in it so if someone changes the link, brew will give an error.

If you `brew fetch wysenynja/bitcoin/armory-qt` it will output the url and the hashes for the downloaded file without installing it.

You could also fork my bitcoin tap and use git to sign those release commits.

Do you think it would be [reasonably] possible to create a .dmg with all the dependencies?  Or is it a s***load of code to bundle?  It sounds like the script that goes and picks up the dependencies from brew is ideal, efficiency-wise, but does leave open subtle attack vectors (poisoning brew modules?).  I don't know ... I really want to support OSX users, but I have so little OSX experience...

The dmg isn't the hard part.  Getting it into an app is the hard part.  I haven't experimented too much recently, but it was a PITA previously and I never really got it working.  I'll look at how electrum does it and try it again when I get the time.

I think a poisoned brew formula is highly unlikely.  The security paranoid could check hashes for all of the modules if they wish.  Brew can output a list of all the dependencies and you could check all of their hashes.  A script could feasibly be written to do this, but IMHO, it doesn't really matter.  Any significant amount of funds should be on an offline computer.

Here is a gist with my osx instructions for the people that want to do it all by hand. https://gist.github.com/4200620

I would definitely recommend the brew tap though as it is much easier and sets up a nice "ArmoryQt.command" for you

[etotheipi]

Do you think it would be [reasonably] possible to create a .dmg with all the dependencies?  Or is it a s***load of code to bundle?  It sounds like the script that goes and picks up the dependencies from brew is ideal, efficiency-wise, but does leave open subtle attack vectors (poisoning brew modules?).  I don't know ... I really want to support OSX users, but I have so little OSX experience...

The dmg isn't the hard part.  Getting it into an app is the hard part.  I haven't experimented too much recently, but it was a PITA previously and I never really got it working.  I'll look at how electrum does it and try it again when I get the time.

I think a poisoned brew formula is highly unlikely.  The security paranoid could check hashes for all of the modules if they wish.  Brew can output a list of all the dependencies and you could check all of their hashes.  A script could feasibly be written to do this, but IMHO, it doesn't really matter.  Any significant amount of funds should be on an offline computer.

Some users still want to exercise some degree of due diligence on the install process for sanity's sake.  Not to mention, they may be using this script to setup an soon-to-be-offline OSX system...

I just need to dig in a bit more to see what it's doing before I can "bless it".  On that note, I just ran your 4-5 commands in my OSX VM ... slow as dirt (I think it's the VM), but it did work.  I'm looking at an Armory wallet and a couple tx in OSX.  I was at least able to get into the paper backup dialog so I could copy down the characters by hand, if necessary.

Very cool!  Thanks for doing this Red Emerald.  You have made it possible for even-mildly-determined users to get access to Armory!  (maybe I'll change the donation address to point to you when OS_MACOSX is detected, for one release cycle )

[Red Emerald]

Some users still want to exercise some degree of due diligence on the install process for sanity's sake.  Not to mention, they may be using this script to setup an soon-to-be-offline OSX system...

Definitely a good idea to be paranoid with financial software.  I imagine the number of offline osx systems is going to be tiny.  Seems like linux would make more sense for the paranoid since it's possible to audit the entire codebase.

I just need to dig in a bit more to see what it's doing before I can "bless it".  On that note, I just ran your 4-5 commands in my OSX VM ... slow as dirt (I think it's the VM), but it did work.  I'm looking at an Armory wallet and a couple tx in OSX.  I was at least able to get into the paper backup dialog so I could copy down the characters by hand, if necessary.

Sounds good.  Let me know if you have any questions.  Brew formula are pretty simple.  No need to know Ruby or really even how to program.  VMs are almost always slower than a native machine.  It should work to test though.  I still have a problem where the text is cropped a bit until I resize the window.  I'm sure its one of many OSX pyqt bugs that has little to do with your code, but you should be able to see the weird UI issues on your VM.

Very cool!  Thanks for doing this Red Emerald.  You have made it possible for even-mildly-determined users to get access to Armory!  (maybe I'll change the donation address to point to you when OS_MACOSX is detected, for one release cycle )

Thanks for the awesome client!  Without armory I'm not sure how I would store my savings securely.

[etotheipi]

Do your commands work on a fresh install of OSX without having brew or xcode previously installed?  It looks like they depend on brew being installed already (I had actually installed it in my VM before, which is why it worked).  Just need a reminder of how to get those pre-reqs installed...

Perhaps you could also keep the almost-top post updated with the latest instructions and I'll just link to that from the BitcoinArmory.com page.  They wouldn't have to be updated often (and I'll remind you when they do ).  I just want something to link to from the building-from-source page, and I don't think it makes sense for me to maintain it, if you don't mind doing it yourself.  It also makes sure users are aware that it didn't come directly from me...

[Red Emerald]

Do your commands work on a fresh install of OSX without having brew or xcode previously installed?  It looks like they depend on brew being installed already (I had actually installed it in my VM before, which is why it worked).  Just need a reminder of how to get those pre-reqs installed...

Perhaps you could also keep the almost-top post updated with the latest instructions and I'll just link to that from the BitcoinArmory.com page.  They wouldn't have to be updated often (and I'll remind you when they do ).  I just want something to link to from the building-from-source page, and I don't think it makes sense for me to maintain it, if you don't mind doing it yourself.  It also makes sure users are aware that it didn't come directly from me...

Brew and xcode need to be installed first.  I can add that to the directions, if you think I should.

You should link to this gist rather than the forum post: https://gist.github.com/4200620

I'll keep it up to date, and its easier for people to see changes there.

[etotheipi]

Brew and xcode need to be installed first.  I can add that to the directions, if you think I should.

You should link to this gist rather than the forum post: https://gist.github.com/4200620

I'll keep it up to date, and its easier for people to see changes there.

Yeah, I think it should be there.  I want there to be a clear path to success for anyone who is determined.  I don't expect all OSX users to type commands into this mysitical black box (terminal) to get some program they've only heard about -- but I want it to be as straightforward as possible -- no missing steps -- for users who are determined to get Armory, but have no experience with this stuff.

It's probably just a transient solution.  I'm sure we'll find a way to bundle it up...eventually.  On that note, here is a message that jim618 (creator of Multibit) sent me after I requested some help.  I apologize in advance for posting a PM in a public thread without permission, but I'm sure he'll forgive me

The packaging for OSX is not too bad. I have not done the app developer signing yet but here is how I have done the basic packaging.

The 'app' file that users double click to start your application is just a directory in a very particular format specified by Apple.
The easiest way to get one working is to simply reverse engineer an existing one and tweak it.
In my build I have a skeleton app in source control and then just add the built MultiBit jar as a 'payload'.

The skeleton is here:
https://github.com/jim618/multibit/tree/v0.5/src/app-resources

Also the app configuration and metadata is in the /Contents/Info.plist - that is the place to put the bitcoin URI binding etc.

You can create your app directory manually and get it to work, and then you have something concrete for your build to create. That's what I did.

Once you have an Armory app directory in the correct format (OSX shows it as a single file but it is really a directory) you have your working app. You could actually distribute it like that but the Mac convention is to have a disk image (a DMG file) with:
1) the app
2) a shortcut to the applications dir so that the user can drag the app in
3) readme/ licensing/ whatever

To create the DMG file I use the command 'hdiutil' in my project build file:
https://github.com/jim618/multibit/blob/v0.5/pom.xml

if you search for 'create-mac-dmg'. It is all unix commands wrapped up in ant so you can probably do something similar.

[Red Emerald]

Okay.  I've added a lot more detail to the gist.  Let me know if I should add more.

https://gist.github.com/4200620

[picobit]

It does not look like making an app is that hard - I made one by accident the other day

While looking for a solution to the printing problem in Mac OS X, I found a small test example showing a similar problem.  The test example consists of three small source files, bulding into a .app !

You can find the files print.pro, print.h and main.cpp here: https://bugreports.qt-project.org/browse/QTBUG-17913
Then you just type "qmake" at the command line, and qmake writes a Makefile.  The Makefile then builds print.app

It should be possible to work out how the Makefile does it, at least if you cheat and look in the print.app directory as well.  The "Application Bundle" (.app) is a directory that MacOS insists on showing like a file.  I don't know if it is the .app suffix or a special file attribute that does the hiding.

[picobit]

Just tried Red Emerald's brew tap.  It works as expected, thanks a lot!

Regarding the trust chain:  I think it would be a good idea if etotheipi publishes the SHA hash of Red Emerald's brew script on his web page.  Then users can verify that script, and as the script contains the SHA of the downloaded tar file, that is automatically verified as well.  The only remaining attack vector is then malicious code put into some of the dependencies, but that would then almost have to be done by somebody outside the bitcoin ecosystem.  I am not sufficiently paranoid to worry about that.

Of course etotheipi or Red Emerald could SHA sign all the dependencies as well, but that would honestly be a PITA since they are updated without warning.

[Red Emerald]

It does not look like making an app is that hard - I made one by accident the other day

While looking for a solution to the printing problem in Mac OS X, I found a small test example showing a similar problem.  The test example consists of three small source files, bulding into a .app !

You can find the files print.pro, print.h and main.cpp here: https://bugreports.qt-project.org/browse/QTBUG-17913
Then you just type "qmake" at the command line, and qmake writes a Makefile.  The Makefile then builds print.app

It should be possible to work out how the Makefile does it, at least if you cheat and look in the print.app directory as well.  The "Application Bundle" (.app) is a directory that MacOS insists on showing like a file.  I don't know if it is the .app suffix or a special file attribute that does the hiding.

Thanks.  I'll play with this later tonight.  It's easy to build a generic .app, but it becomes harder when it has to include python and pyqt.

The .app suffix is just a suffix.  You can name any folder.app and if it has the right structure, it will run.

Just tried Red Emerald's brew tap.  It works as expected, thanks a lot!

Regarding the trust chain:  I think it would be a good idea if etotheipi publishes the SHA hash of Red Emerald's brew script on his web page.  Then users can verify that script, and as the script contains the SHA of the downloaded tar file, that is automatically verified as well.  The only remaining attack vector is then malicious code put into some of the dependencies, but that would then almost have to be done by somebody outside the bitcoin ecosystem.  I am not sufficiently paranoid to worry about that.

Of course etotheipi or Red Emerald could SHA sign all the dependencies as well, but that would honestly be a PITA since they are updated without warning.

Glad it worked for you!

A hash of the formula could work.  That would be easy to verify.  I'm hesitant to write a script to do all of the validation since it seems like if someone is in place to maliciously modify a package, they might also be able to modify the check script.  Of course if it's something as simple as fetching a signed hash from etotheipi's site and making sure it matches the local hash, this should be easy to do in a single line.

Code:

$ brew fetch --deps Wysenynja/bitcoin/armory-qt
Fetching: armory-qt, cryptopp, pcre, swig, sip, libpng, qt, pyqt
==> Downloading https://github.com/etotheipi/BitcoinArmory/archive/v0.85-beta.tar.gz
Already downloaded: /Library/Caches/Homebrew/armory-qt-v0.85-beta.tar.gz
MD5:  762e5d0f5c4816cc1686aecd32c9a2a8
SHA1: 26354bdb5096ea4a9aeccbf1c80e103fb89c72a1
SHA256: 2102ad70e05567de07a985dc53a1b41d373649a8a5e7c82387d2ef4192d5c3fb
==> Downloading http://downloads.sourceforge.net/project/cryptopp/cryptopp/5.6.1/cryptopp561.zip
######################################################################## 100.0%
Downloaded to: /Library/Caches/Homebrew/cryptopp-5.6.1.zip
MD5:  96cbeba0907562b077e26bcffb483828
SHA1: 31dbb456c21f50865218c57b7eaf4c955a222ba1
SHA256: 98e74d8cb17a38033354519ac8ba9c5d98a6dc00bf5d1ec3c533c2e8ec86f268
==> Downloading ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.31.tar.bz2
Already downloaded: /Library/Caches/Homebrew/pcre-8.31.tar.bz2
MD5:  1c9a276af932b5599157f96e945391f0
SHA1: 1132276bb8bea7cb0662210fb812fbef7791621f
SHA256: 5778a02535473c7ee7838ea598c19f451e63cf5eec0bf0307a688301c9078c3c
==> Downloading http://downloads.sourceforge.net/project/swig/swig/swig-2.0.8/swig-2.0.8.tar.gz
Already downloaded: /Library/Caches/Homebrew/swig-2.0.8.tar.gz
MD5:  69f917e870efc0712c06ab53217b28d1
SHA1: 763305da320163903c69c1cdfbf9a942117d9ace
SHA256: aeeefa20bbe1c03bacf23f0af9e7d6193e8b807b7585470615b71b1ee0c8ca4f
==> Downloading http://www.riverbankcomputing.co.uk/hg/sip/archive/4.13.3.tar.gz
Already downloaded: /Library/Caches/Homebrew/sip-4.13.3.tar.gz
MD5:  b5740125c635f796a72c140f2a2e48c5
SHA1: 672f0bd9c13860979ab2a7753b2bf91475a4deeb
SHA256: baedbc8ba8657ded7e8831c35a6af118e50a9d95f9c90c0fa39cc3c392ddaf1a
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/libpng-1.5.13.mountainlion.bottle.tar.gz
Already downloaded: /Library/Caches/Homebrew/libpng-1.5.13.mountainlion.bottle.tar.gz
MD5:  18dae128d2cb1b7d23b5d08b008d1f8b
SHA1: 382eb757c38a4c326410a42deab8b4a8c22a6c13
SHA256: 88e5015ac3858cdc39431f1ce781c89bf1bffe09963573b8df83125095a65f23
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/qt-4.8.3.mountainlion.bottle.tar.gz
Already downloaded: /Library/Caches/Homebrew/qt-4.8.3.mountainlion.bottle.tar.gz
MD5:  0878f24da24c8398574a41d86fc6ef14
SHA1: ff488747325cd6771fbf0b79156fd3833ff3af63
SHA256: 47943315ea7cca39075611cdfb35fe6b1ab451436bda099c00c02ca2d291928d
==> Downloading http://downloads.sf.net/project/pyqt/PyQt4/PyQt-4.9.4/PyQt-mac-gpl-4.9.4.tar.gz
Already downloaded: /Library/Caches/Homebrew/pyqt-4.9.4.tar.gz
MD5:  e31dae8ff5294086ed5de6b9a4215b1b
SHA1: 3fe827fed91ec710746fa980f433313dfec2d5fd
SHA256: f7c21007277fb8e8e90f1d55ed96bda8d5f08f1c2b78cf39928416bcdb24b70e

Brew does make this pretty easy.  Etotheipi or I could sign that, but it would change a lot as brew updates VERY frequently.  It also wouldn't catch a malicious formula (although as I said earlier, that is extremely paranoid).

[gweedo]

Bug report:
OS: Mac OSX 10.8.2
Armory Version:       0.85
PyBtcWallet  Version: 1.35

Armory just loses connected and it seems like it is infinite loop, that just keeps printing this out over and over, but it never crashes completely and sometimes after 10mins of this it will reconnect and work with no problem.
 

Code:

ERROR) armoryengine.py:10344 - Waiting for BDM output that didn't come after 10s.
(ERROR) armoryengine.py:10345 - BDM state is currently: BlockchainReady
(ERROR) armoryengine.py:10346 - Called from: armoryengine.py:10471 (30189323)
(ERROR) armoryengine.py:10347 - BDM currently doing: ReadBlkUpdate (30189323)
(ERROR) armoryengine.py:10348 - Direct traceback
  File "/usr/local/share/armory/ArmoryQt.py", line 3629, in <module>
    os._exit(QAPP.exec_())
  File "/usr/local/Cellar/armory-qt/beta/share/armory/qt4reactor.py", line 231, in _iterate
    self.runUntilCurrent()
  File "/usr/local/lib/python2.7/site-packages/twisted/internet/base.py", line 800, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/local/share/armory/ArmoryQt.py", line 3247, in Heartbeat
    newBlocks = TheBDM.readBlkFileUpdate(wait=True)
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10471, in readBlkFileUpdate
    return self.waitForOutputIfNecessary(expectOutput, rndID)
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10349, in waitForOutputIfNecessary
    traceback.print_stack()
(ERROR) armoryengine.py:10350 - Traceback:
Traceback (most recent call last):
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10340, in waitForOutputIfNecessary
    return self.outputQueue.get(True, MT_WAIT_TIME_SEC)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Queue.py", line 176, in get
    raise Empty
Empty

[Red Emerald]

Bug report:
OS: Mac OSX 10.8.2
Armory Version:       0.85
PyBtcWallet  Version: 1.35

Armory just loses connected and it seems like it is infinite loop, that just keeps printing this out over and over, but it never crashes completely and sometimes after 10mins of this it will reconnect and work with no problem.
 

Code:

ERROR) armoryengine.py:10344 - Waiting for BDM output that didn't come after 10s.
(ERROR) armoryengine.py:10345 - BDM state is currently: BlockchainReady
(ERROR) armoryengine.py:10346 - Called from: armoryengine.py:10471 (30189323)
(ERROR) armoryengine.py:10347 - BDM currently doing: ReadBlkUpdate (30189323)
(ERROR) armoryengine.py:10348 - Direct traceback
  File "/usr/local/share/armory/ArmoryQt.py", line 3629, in <module>
    os._exit(QAPP.exec_())
  File "/usr/local/Cellar/armory-qt/beta/share/armory/qt4reactor.py", line 231, in _iterate
    self.runUntilCurrent()
  File "/usr/local/lib/python2.7/site-packages/twisted/internet/base.py", line 800, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "/usr/local/share/armory/ArmoryQt.py", line 3247, in Heartbeat
    newBlocks = TheBDM.readBlkFileUpdate(wait=True)
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10471, in readBlkFileUpdate
    return self.waitForOutputIfNecessary(expectOutput, rndID)
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10349, in waitForOutputIfNecessary
    traceback.print_stack()
(ERROR) armoryengine.py:10350 - Traceback:
Traceback (most recent call last):
  File "/usr/local/Cellar/armory-qt/beta/share/armory/armoryengine.py", line 10340, in waitForOutputIfNecessary
    return self.outputQueue.get(True, MT_WAIT_TIME_SEC)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Queue.py", line 176, in get
    raise Empty
Empty

What version of bitcoind?  Was bitcoind doing anything at the time? Was it responsive (to a command like getinfo) while this was happening?

[gweedo]

What version of bitcoind?  Was bitcoind doing anything at the time? Was it responsive (to a command like getinfo) while this was happening?

Bitcoind is 0.7.0

nothing, it could have been getting the lastest block, since both were on 210888 and when it went to 210889 that is when the issue started cause on armory in the corner it would go from "Disconnected" to "Connected >" to "Connected (210889 blocks)" and just keep looping until I quit armory and normally, no force quit.

Yes Bitcoind was responsive and it is still running

[etotheipi]

What version of bitcoind?  Was bitcoind doing anything at the time? Was it responsive (to a command like getinfo) while this was happening?

Bitcoind is 0.7.0

nothing, it could have been getting the lastest block, since both were on 210888 and when it went to 210889 that is when the issue started cause on armory in the corner it would go from "Disconnected" to "Connected >" to "Connected (210889 blocks)" and just keep looping until I quit armory and normally, no force quit.

Yes Bitcoind was responsive and it is still running

We were just having a discussion about this on the main Armory thread.  I'm investigating right now.  Unfortunately, the new multi-threaded design doesn't handle certain errors right now, and run off into a loop.  But so far, this >10s call to readBlkFileUpdate is the only operation I've seen trigger this bad loop.  Hopefully I'll figure it out soon.

[etotheipi]

Red Emerald,

Do fresh OSX users need to install xcode?  That's not in the instructions.

And I wonder if there's a way to avoid having the user manually modify their .bashrc.  I guess a short script could just run all of those commands for them...?  Actually couldn't all of this be bundled into a script?

Sorry I'm being picky, I just see a lot of hurdles for non-techie mac users...

[Red Emerald]

Red Emerald,

Do fresh OSX users need to install xcode?  That's not in the instructions.

And I wonder if there's a way to avoid having the user manually modify their .bashrc.  I guess a short script could just run all of those commands for them...?  Actually couldn't all of this be bundled into a script?

Sorry I'm being picky, I just see a lot of hurdles for non-techie mac users...

Yes, they need to install Xcode for brew to work.  It is in the instructions.  https://gist.github.com/4200620

brew doctor will tell you to install xcode and the command line tools if you need to.

I've made the bashrc stuff easier to do for the non-technical. Someone with an existing bashrc is probably technical enough to know how to do this on their own, but this should work fine for anyone who already has a bashrc.

[Gavin Andresen]

RE: building the .app bundle:

https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/macdeployqtplus
... is python code with lots of useful stuff for building a nice .app (including making a pretty-looking .dmg).
Lots of Qt-specific stuff, too, but it might be a good starting point.

[etotheipi]

RE: building the .app bundle:

https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/macdeployqtplus
... is python code with lots of useful stuff for building a nice .app (including making a pretty-looking .dmg).
Lots of Qt-specific stuff, too, but it might be a good starting point.

Thanks Gavin, that looks great -- albeit big, and might take me a while to figure out what to do with it.  But anything helps!  Especially if it already includes Qt (but I'll need PyQt, too).


@RedEmerald

I just tried the git tag signing, and it worked flawlessly.  I don't know why I didn't do this before...

Code:

git pull
git tag -v "v0.86-beta"

That should confirm that the tag is signed by the "Armory Signing Key."  About to do the 0.86-beta release, with CoinControl and the double-tx bugfix.

[picobit]

Red Emerald:

Are you going to release 0.86 in homebrew, too?  Not that it is hard to compile by myself, but your homebrew formula is easier

[Red Emerald]

Red Emerald:

Are you going to release 0.86 in homebrew, too?  Not that it is hard to compile by myself, but your homebrew formula is easier

Updated! Sorry for the delay.

Code:

brew update
brew doctor
brew fetch --deps armory-qt
brew upgrade armory-qt

Once it's installed, you don't need to prefix armory-qt with "wysenynja/bitcoin/"

A fresh install does tho:

Code:

brew update
brew doctor
brew tap WyseNynja/bitcoin
brew fetch --deps wysenynja/bitcoin/armory-qt
brew install wysenynja/bitcoin/armory-qt

Note that case matters for `tap`, but not for the other commands.

[picobit]

Wow, you are amazingly fast!

I can confirm that it works as expects (i.e. great).

The "brew fetch" command is not really necessary, but I guess that it gives the truly paranoid a chance to check what is being installed.

Thank you very much, indeed!

[bitcoins5411]

Can't we just come up with a DMG file with an installer for all of us who don't like to deal with compilers, etc? Can't we get a mac release that doesn't take so much work to get it up and running?

Is that a crazy request?

[Red Emerald]

Wow, you are amazingly fast!

I can confirm that it works as expects (i.e. great).

Pretty much all it takes is changing the 2 lines in the formula (the download link and the file hash), so it's pretty easy. Glad it worked for you!

The "brew fetch" command is not really necessary, but I guess that it gives the truly paranoid a chance to check what is being installed.

Thank you very much, indeed!

Yeah, it isn't necessary.  I figured I might as well provide the most paranoid level of instructions as the default though.

Can't we just come up with a DMG file with an installer for all of us who don't like to deal with compilers, etc? Can't we get a mac release that doesn't take so much work to get it up and running?

Is that a crazy request?

That's the end goal.  However it is more work than providing a brew formula.  It's been a pain so far to compile custom c extensions and pyqt into a distributable app.

[Red Emerald]

I've updated the tap again!  It's now using git to checkout v0.86.3-beta and then checks to make sure the git tag is valid.

To update your existing install:

Code:

brew update
brew doctor
brew fetch --deps armory-qt
brew upgrade armory-qt

To install fresh:

Code:

brew update
brew doctor
brew tap WyseNynja/bitcoin
brew fetch --deps wysenynja/bitcoin/armory-qt
brew install wysenynja/bitcoin/armory-qt

You will need to have imported etotheipi's key for verifying the tag to work.

RSA key ID 98832223 "Alan C. Reiner (Armory Signing Key) <alan.reiner@gmail.com>"

You can skip the tag checking by adding "--skip-verify" "--without-gpg" to the install/upgrade command

[Red Emerald]

I've added support for the "--devel" flag!  You can use it to easily install the "testing" branch of armory-qt.

I've also setup a thread for my brew tap.  https://bitcointalk.org/index.php?topic=133097.0

[Rampion]

May I ask how far away in time is an Armory OSX bundle?

Thanks

[etotheipi]

May I ask how far away in time is an Armory OSX bundle?

Thanks

There are two main factors to answering that question/request:

(1) While Armory is still a fairly advanced program and Red Emerald has done a fantastic job helping people get it going on OSX, I have put this slightly lower in priority.  Mainly because I know nothing about OSX, and it's currently accessible to those that really want it.  When I finally get Armory's usability up to par, then I will make it a high priority to bring that usability to all platforms (and right now, there are some pretty epic usability improvements in the works).

(2) Everything I just said in #1 is based on getting no help from anyone else.  If someone else were to make an OSX bundle of Armory for me, and then give me what I need to know to understand how it was made and can rebuild/update it myself... then I can bump it way up in priority.  It's current priority is based on how much else has to be put on hold while I figure it out.  If someone gives me what I need to figure it out in day or two, there's no reason for me not to do it right way.

[Red Emerald]

(2) Everything I just said in #1 is based on getting no help from anyone else.  If someone else were to make an OSX bundle of Armory for me, and then give me what I need to know to understand how it was made and can rebuild/update it myself... then I can bump it way up in priority.  It's current priority is based on how much else has to be put on hold while I figure it out.  If someone gives me what I need to figure it out in day or two, there's no reason for me not to do it right way.

I've given it a good try a couple times, but pyinstaller barfs on some macholib errors that I haven't been able to sort out and py2app does similarly

When I gave up on that, I made the brew tap.

[etotheipi]

(2) Everything I just said in #1 is based on getting no help from anyone else.  If someone else were to make an OSX bundle of Armory for me, and then give me what I need to know to understand how it was made and can rebuild/update it myself... then I can bump it way up in priority.  It's current priority is based on how much else has to be put on hold while I figure it out.  If someone gives me what I need to figure it out in day or two, there's no reason for me not to do it right way.

I've given it a good try a couple times, but pyinstaller barfs on some macholib errors that I haven't been able to sort out and py2app does similarly

When I gave up on that, I made the brew tap.

That's pretty bad news for me.  I have pretty much never used OSX for anything, and if you can't get it working,  I'm pretty sure it's going to be a total bear for me. 

On the upside,  the satoshi client uses Qt,  too (though not python/PyQt),  and they bundle it all up into a pretty OSX package the way I want to do it.   Perhaps we can start from their packaging system and modify it until we get there...  I think Gavin actually responded in this thread a while ago with some links... But I'm on my phone right with poor Internet connection, so I can't really go back and check easily.

Again,  this is something I will make happen at some point but not soon unless users with more OSX experience help.

And Red Emerald, don't feel bad.   You've already helped out so much already!  Without it,  there might not have been any OSX support at all! 

[ErebusBat]

I am very grateful for Red Emeralds work.

[Red Emerald]

Thanks guys!

[Rampion]

I'm trying just now to install Armory on a Macbook Pro running 10.8.2. I installed brew and downloading last version of XCODE and Xcode command line tools.

Will update later

EDIT: everything was going smooth, until I got this errors:

==> ./configure --prefix=/usr/local/Cellar/gnupg/1.4.12 --disable-asm
==> make CFLAGS= -std=gnu89 -fheinous-gnu-extensions
==> make check
==> make install
Warning: Could not link gnupg. Unlinking...
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link gnupg'
==> Summary
🍺  /usr/local/Cellar/gnupg/1.4.12: 54 files, 5,0M, built in 2.1 minutes
==> Installing armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
gpg: /Users/****/.gnupg/gpg.conf:233: invalid auto-key-locate list

and then, when I try to run the client:

MacBook-Pro:~ mr$ ArmoryQt.command
-bash: ArmoryQt.command: command not found

Any idea why this happens? I had installed MacGPG2 before running the commands, maybe that's a problem? I tryed "brew link gnupg" and I get this:

MacBook-Pro:~ mr$ brew link gnupg
Linking /usr/local/Cellar/gnupg/1.4.12... Warning: Could not link gnupg. Unlinking...

Error: Could not symlink file: /usr/local/Cellar/gnupg/1.4.12/bin/gpg
Target /usr/local/bin/gpg already exists. You may need to delete it.
To force the link and delete this file, do:
  brew link --overwrite formula_name

To list all files that would be deleted:
  brew link --overwrite --dry-run formula_name
MacBook-Pro:~ mr$ brew link --overwrite --dry-run formula_name
Error: No such keg: /usr/local/Cellar/formula_name

I'm afraid that deleting those files could make me loose my private GPG key... Any idea of how to proceed?

[picobit]

Yes, a sufficiently old MacGPG will cause that kind of problems.  I uninstalled mine and allowed Homebrew's gnupg to install, but then I have never been able to get MacGPG to work even in a remotely satisfactory way, and the newest version does not yet support Mountain Lion.

Do not worry about your private GPG keys, surely you have them backed up in three different places already.  
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!

[ErebusBat]

I had all sort of troubles caused by MacGPG, even after I uninstalled it.   I think I ven had to force brew to link the files to move on.

[Rampion]

Yes, a sufficiently old MacGPG will cause that kind of problems.  I uninstalled mine and allowed Homebrew's gnupg to install, but then I have never been able to get MacGPG to work even in a remotely satisfactory way, and the newest version does not yet support Mountain Lion.

Do not worry about your private GPG keys, surely you have them backed up in three different places already.  
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!

This seems like a serious problem. I use GPG daily, mostly to encrypt files... I cannot risk to not being able to use it again

I had all sort of troubles caused by MacGPG, even after I uninstalled it.   I think I ven had to force brew to link the files to move on.

I tried the brew link gnupg" and I got this error:

MacBook-Pro:~ mr$ brew link gnupg
Linking /usr/local/Cellar/gnupg/1.4.12... Warning: Could not link gnupg. Unlinking...

Error: Could not symlink file: /usr/local/Cellar/gnupg/1.4.12/bin/gpg
Target /usr/local/bin/gpg already exists. You may need to delete it.
To force the link and delete this file, do:
  brew link --overwrite formula_name

To list all files that would be deleted:
  brew link --overwrite --dry-run formula_name
MacBook-Pro:~ mr$ brew link --overwrite --dry-run formula_name
Error: No such keg: /usr/local/Cellar/formula_name

I really hope Red Emerald could find a workaround for this

[picobit]

The GPG stuff is only used to validate the downloads.  In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.

[Rampion]

The GPG stuff is only used to validate the downloads.  In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.

Do you think it's safe to disable the GPG check? Armory handles sensitive stuff

[Rampion]

The GPG stuff is only used to validate the downloads.  In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.

I tried

brew install --skip-verify wysenynja/bitcoin/armory-qt

AND

brew install wysenynja/bitcoin/armory-qt --skip-verify

I still get:

Error: You must `brew link gnupg' before armory-qt can be installed

[picobit]

Do you think it's safe to disable the GPG check? Armory handles sensitive stuff

You can always download first, and check signatures manually.  But if you are really paranoid: no.  But have you checked that the homebrew script actually checks the gpg signatures instead of just pretending to do so and install something nasty?

[Red Emerald]

The GPG stuff is only used to validate the downloads.  In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.

I tried

brew install --skip-verify wysenynja/bitcoin/armory-qt

I still get:

Error: You must `brew link gnupg' before armory-qt can be installed

Sorry about that.

I've tweaked the formula, and it should work better now.

Instead of "--skip-verify," now you can use "--without-gpg" and brew should be smart enough to skip the installation step.

Additionally, I just bumped the version to 0.87-beta.  As always, you can use "--devel" to install the testing branch.

Code:

brew update
brew install wysenynja/bitcoin/armory-qt --without-gpg

About gpgtools and OSX Mountain Lion.  If you donate (hint: they accept bitcoin), you can get early access to the beta.  Just send them an email with a signed txid and a message saying how awesome they are.  I have had both brew's gpg and gpgtools beta installed without problem for months now.

[Red Emerald]

I'm trying just now to install Armory on a Macbook Pro running 10.8.2. I installed brew and downloading last version of XCODE and Xcode command line tools.

Will update later

EDIT: everything was going smooth, until I got this errors:

==> ./configure --prefix=/usr/local/Cellar/gnupg/1.4.12 --disable-asm
==> make CFLAGS= -std=gnu89 -fheinous-gnu-extensions
==> make check
==> make install
Warning: Could not link gnupg. Unlinking...
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link gnupg'
==> Summary
🍺  /usr/local/Cellar/gnupg/1.4.12: 54 files, 5,0M, built in 2.1 minutes
==> Installing armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
gpg: /Users/xxxxxx/.gnupg/gpg.conf:233: invalid auto-key-locate list

and then, when I try to run the client:

MacBook-Pro:~ mr$ ArmoryQt.command
-bash: ArmoryQt.command: command not found

Well of course you can't run "ArmoryQt.command" if the install fails

This error means there is more than likely an error in your gpg.conf.  Can you make sure nothing is sensitive in there and then post the contents here?  I don't think this is a problem with brew.

In the mean time, read my post above for working around gpg.

[Red Emerald]

Do you think it's safe to disable the GPG check? Armory handles sensitive stuff

You can always download first, and check signatures manually.  But if you are really paranoid: no.  But have you checked that the homebrew script actually checks the gpg signatures instead of just pretending to do so and install something nasty?

I highly encourage everyone check out the formula code.  It's only 64 lines with blank lines and some comments and you don't even need to know ruby (I don't) or really even know how to program at all to read it.

I also recommend that you read the source for everything you install, but that is probably more difficult for non-programmers and programmers with not-enough time (e.g. all programmers).  The formula is really strait forward. 

Code:

cat `brew --prefix`/Library/Taps/wysenynja-bitcoin/armory-qt.rb

Or read it on github.

[Rampion]

I've tweaked the formula, and it should work better now.

That did it! Genius! It's scanning the blockchain at the moment

I just realized that this process is not going to work on the old offline computer I was going to use for cold storage, which is also an old macbook pro... I think I will just format it and install Ubuntu then.

This error means there is more than likely an error in your gpg.conf.  Can you make sure nothing is sensitive in there and then post the contents here?  I don't think this is a problem with brew.

In the mean time, read my post above for working around gpg.

Well, the truth is that i have NO gpg.conf on my computer

EDIT: I found the file, but OSX's finder took forever to find it. Here are the contents:

# These first three lines are not copied to the gpg.conf file in
# the users home directory.
# $Id$
# Options for GnuPG
# Copyright 1998, 1999, 2000, 2001, 2002, 2003,
#           2010 Free Software Foundation, Inc.
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you specify which option file to use (with the command line
# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf
# by default.
#
# An options file can contain any long options which are available in
# GnuPG. If the first non white space character of a line is a '#',
# this line is ignored.  Empty lines are also ignored.
#
# See the man page for a list of options.

# Uncomment the following option to get rid of the copyright notice

#no-greeting

# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.

#default-key <TAKEN OUT>

# If you do not pass a recipient to gpg, it will ask for one.  Using
# this option you can encrypt to a default key.  Key validation will
# not be done in this case.  The second form uses the default key as
# default recipient.

#default-recipient some-user-id
#default-recipient-self

# By default GnuPG creates version 4 signatures for data files as
# specified by OpenPGP.  Some earlier (PGP 6, PGP 7) versions of PGP
# require the older version 3 signatures.  Setting this option forces
# GnuPG to create version 3 signatures.

#force-v3-sigs

# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you may want to use this option.

#no-escape-from-lines

# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification.  However for new
# installations it should be enabled.

require-cross-certification


# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set.  Please check the man page
# for supported character sets.  This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation.  Note that future version of GnuPG will change to UTF-8
# as default character set.

#charset utf-8

# Group names may be defined like this:
#   group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678".  Note there is only one level of expansion - you
# cannot make an group that points to another group.  Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients.  In these cases it is better to use the key ID.

#group mynames = paige 0x12345678 joe patti

# Some old Windows platforms require 8.3 filenames.  If your system
# can handle long filenames, uncomment this.

#no-mangle-dos-filenames

# Lock the file only once for the lifetime of a process.  If you do
# not define this, the lock will be obtained and released every time
# it is needed - normally this is not needed.

#lock-once

# GnuPG can send and receive keys to and from a keyserver.  These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyservers:
#      hkp://keys.gnupg.net
#      hkp://subkeys.pgp.net
#
# Example email keyserver:
#      mailto:pgp-public-keys@keys.pgp.net
#
# Example LDAP keyservers:
#      ldap://pgp.surfnet.nl:11370
#      ldap://keyserver.pgp.com
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
#      hkp://keyserver.example.net:22742
#
# If you have problems connecting to a HKP server through a buggy http
# proxy, you can use keyserver option broken-http-proxy (see below),
# but first you should make sure that you have read the man page
# regarding proxies (keyserver option honor-http-proxy)
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other.  Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin.  hkp://keys.gnupg.net is an example of
# such a "server", which spreads the load over a number of physical
# servers.  To see the IP address of the server actually used, you may use
# the "--keyserver-options debug".

keyserver hkp://keys.gnupg.net
#keyserver http://http-keys.gnupg.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://pgp.surfnet.nl:11370
#keyserver ldap://keyserver.pgp.com

# Common options for keyserver functions:
#
# include-disabled = when searching, include keys marked as "disabled"
#                    on the keyserver (not all keyservers support this).
#
# no-include-revoked = when searching, do not include keys marked as
#                      "revoked" on the keyserver.
#
# verbose = show more information as the keys are fetched.
#           Can be used more than once to increase the amount
#           of information shown.
#
# use-temp-files = use temporary files instead of a pipe to talk to the
#                  keyserver.  Some platforms (Win32 for one) always
#                  have this on.
#
# keep-temp-files = do not delete temporary files after using them
#                   (really only useful for debugging)
#
# honor-http-proxy = if the keyserver uses HTTP, honor the http_proxy
#                    environment variable
#
# broken-http-proxy = try to work around a buggy HTTP proxy
#
# auto-key-retrieve = automatically fetch keys as needed from the keyserver
#                     when verifying signatures or when importing keys that
#                     have been revoked by a revocation key that is not
#                     present on the keyring.
#
# no-include-attributes = do not include attribute IDs (aka "photo IDs")
#                         when sending keys to the keyserver.

keyserver-options auto-key-retrieve

# Uncomment this line to display photo user IDs in key listings and
# when a signature from a key with a photo is verified.

#show-photos

# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input.  If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# The default program is "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"
# On Mac OS X and Windows, the default is to use your regular JPEG image
# viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
# photo-viewer "display -title 'KeyID 0x%k'"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"

#  *** Options for GPGTools ***

# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option.  This happens when encrypting to an email
# address (in the "user@example.com" form), and there are no
# user@example.com keys on the local keyring.  This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
#        GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
#        CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
#        "ldap://keys.(thedomain)".  For example, encrypting to
#        user@example.com will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
#             the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net

comment GPGTools - http://gpgtools.org

[Red Emerald]

# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option.  This happens when encrypting to an email
# address (in the "user@example.com" form), and there are no
# user@example.com keys on the local keyring.  This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
#        GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
#        CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
#        "ldap://keys.(thedomain)".  For example, encrypting to
#        user@example.com will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
#             the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net

comment GPGTools - http://gpgtools.org

[/quote]

So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it.  Try making it look like this:

# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net

#comment GPGTools - http://gpgtools.org

[/quote]

[Rampion]

So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it.  Try making it look like this:

Done. What should I do to check that now is working?

[Red Emerald]

Code:

Downloading ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.12.tar.bz2

curl: (56) Recv failure: Operation timed out
Error: Download failed: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.12.tar.bz2

I keep getting this error anyway to bypass this? Even in my browser that FTP timesout

Works for me

Maybe they were down for a bit and you got unlucky.

[Red Emerald]

So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it.  Try making it look like this:

Done. What should I do to check that now is working?

You could uninstall and reinstall.  Or just wait until the next version comes out and if a `brew upgrade` works, then you are good to go.

[Rampion]

Having some issues with Armory lately and new bitcoin 0.8.0, on OSX 10.8.2 (Macbook Pro 5,4 / 2.53 GHz Intel Core 2 Dup / 4 GB RAM

- it takes forever to scan the block chain every time I start it (30/40 minutes)
- after some time running flawlessly, it crashes

I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)

I also get a lot of errors in the Terminal (I could copy them here if they may help)

[picobit]

Having some issues with Armory lately and new bitcoin 0.8.0, on OSX 10.8.2 (Macbook Pro 5,4 / 2.53 GHz Intel Core 2 Dup / 4 GB RAM

- it takes forever to scan the block chain every time I start it (30/40 minutes)

That is certainly unreasonable.  Start Activity Monitor and look for memory usage and swap usage.  I would think 4 GB is enough, but if you have something else that is memory expensive it may not be.

- after some time running flawlessly, it crashes

I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)

I also get a lot of errors in the Terminal (I could copy them here if they may help)

You probably should.  Without that info etotheipi has no chance to guess what went wrong.

[ErebusBat]

You can also use pastebin and then paste that link here

[Rampion]

I'm quite sure now that it is a resources problem. I did a fresh Mountain Lion install and now everything is running smoother, including Armory.

Start up takes 40 minutes, and then it runs flawlessly. Is RAM hungry in any case: with OSX Mail, Chrome, Skype and Bitcoin-QT running there's barely enough RAM for Armory to run. Makes all the system very sluggish, and it looses connection with Bitcoin and crashes if I open too many tabs in Chrome.

[etotheipi]

FYI, I'm hard at work plotting out my move to reduce RAM usage...

But I'm also working on having Armory manage bitcoind/-qt for the user.  I'm fairly confident I can have Armory find Bitcoin-Qt and run it in the background in Linux and Windows, but I don't have a clue in OSX.  And since upgrading my OS, I no longer can get VMware running in order to load my OSX VM (which I spent so much time finally getting working!). 

There will be an option to use Armory the old way (run Bitcoin-Qt yourself, and wait for it to sync), but I want to make that the non-default setting, and just manage it automatically for the user if I can find it.

So, is there a semi-standard location that I can use to go find the Bitcoin installation?   It doesn't have to be precise, I can search directory trees pretty easily with python, but I need a hint of where to go.

[etotheipi]

I don't understand how running a bitcoind under armory will save ram usage?

It won't.  It's an unrelated task.  But it's one that I need to do to make Armory a little more accessible, and quite a bit less error-prone.  No more asking the user to press buttons or start applications at the right times, with wacky behavior if they get it wrong.  It will just "Do the Right Thing" and Armory will look like a single program.

One more thing:  you mentioned "/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt".  Does the default installation include bitcoind?

Thanks for the info, that's exactly what I was looking for!  

[gweedo]

One more thing:  you mentioned "/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt".  Does the default installation include bitcoind?

There isn't an official bitcoind for Mac OSX, there is only bitcoin-qt.

[etotheipi]

One more thing:  you mentioned "/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt".  Does the default installation include bitcoind?

There isn't an official bitcoind for Mac OSX, there is only bitcoin-qt.

Crap!  So then... should I just make "Manage Bitcoin-Qt/bitcoind myself" the only option for OSX?  I think loading Bitcoin-Qt is a problem, because Armory will expect to manage it, but then the user may close it and Armory won't know what to do.  The number of permutations of things I have to handle to implement this is already annoying, I don't want to add that to it.

I assume you can still use RPC with Bitcoin-Qt on OSX?  If not, then it's not even an option.

[etotheipi]

I know that Red Emerald has a homebrew that builds a bitcoind for macs https://github.com/WyseNynja/homebrew-bitcoin/blob/master/bitcoind.rb so you might want to talk to him about that.

You can use RPC with bitcoin-qt on OSX, but you have of course enable it thru the bitcoin.conf file first. You can't pass an argument thru the command line for it, last time I checked it was deprecated I may be wrong on that.

I got the RPC thing figured out -- I securely create it myself if it's not there, before starting bitcoind (using a 128-bit random password).

If the user doesn't have bitcoind available, I want to have a button that will basically get it for them, along with links in case they want to get it themself.  In Windows, this means downloading the .exe into a temp directory and then executing it.  In linux, this may mean setting up the Ubuntu PPA, or downloading and unpacking it for them.  It sounds like there is not really an equivalent option in OSX...

Also, I don't want to bundle bitcoind with Armory, because I don't want to be responsible for quickly releasing new versions of Armory when vulnerabilities are found in Bitcoin-Qt requiring an update.

[picobit]

The lack of a bitcoind in  MacOS is quite unfortunate (and a bit mysterious).  Installing it is not simple (at least not if you are an Armory install script).  I have never bothered, and is using Bitcoin-Qt with Armory.

I would suggest you do the same.  Bitcoin-Qt can take arguments that enable RPC, I saw that somewhere but cannot find it now (someting ugly like "open /Applications/Bitcoin-Qt.app --args args-to-bitcoinqt").  There is not way to start it hidden, but you can hide it after is has come up with this ugly command

Code:

osascript -e 'tell application "System Events" to set visible of application process "Bitcoin-Qt" to false'

I found it here: https://discussions.apple.com/thread/1476240?start=0&tstart=0

<rant> Trying to make a programming language to resemble a natural language results in something that is neither natural for programmers nor for nonprogrammers.  Applescript looks awful. </rant>

It will not hide the splash screen of Bitcoin-Qt, but it will hide the app as soon as the splash screen goes away, even if executed while the splash screen is there (just tried it out of curiosity).

I guess that the best alternative for Mac users is to use Bitcoin-Qt in this way.  The icon will still appear in the dock, however.

[Red Emerald]

The lack of a bitcoind in  MacOS is quite unfortunate (and a bit mysterious).  Installing it is not simple (at least not if you are an Armory install script).  I have never bothered, and is using Bitcoin-Qt with Armory.

I would suggest you do the same.  Bitcoin-Qt can take arguments that enable RPC, I saw that somewhere but cannot find it now (someting ugly like "open /Applications/Bitcoin-Qt.app --args args-to-bitcoinqt").  There is not way to start it hidden, but you can hide it after is has come up with this ugly command

Code:

osascript -e 'tell application "System Events" to set visible of application process "Bitcoin-Qt" to false'

I found it here: https://discussions.apple.com/thread/1476240?start=0&tstart=0

<rant> Trying to make a programming language to resemble a natural language results in something that is neither natural for programmers nor for nonprogrammers.  Applescript looks awful. </rant>

It will not hide the splash screen of Bitcoin-Qt, but it will hide the app as soon as the splash screen goes away, even if executed while the splash screen is there (just tried it out of curiosity).

I guess that the best alternative for Mac users is to use Bitcoin-Qt in this way.  The icon will still appear in the dock, however.

At one point, bitcoind came with Bitcoin.app, but not anymore for some reason I don't know.  That's one of the reasons I made my brew formula.  `brew install bitcoind` is pretty easy.  I'm going to make the formula also create a plist for launchd so you can configure bitcoind to start on login if you want by just making a symlink.

Is starting armory on login something that would be desired? Brew makes it really easy and totally optional.

If you have armory searching for bitcoind on the PATH for linux (Please don't use hard coded paths), you might as well have the same check happen for osx. If they have used my brew formula or compiled it themselves, it will just work. If that search fails, check for /Applications/Bitcoin-Qt.app and launch it with whatever crazy flags make it hidden.  Then if that fails, just tell the user "Armory couldn't find bitcoind or bitcoin-qt installed on your system." and then have system specific links if possible and a link to bitcoin.org if not.

I think that having the user install bitcoind/qt and armory smart enough to find it is plenty fine and is definitely going to be exponentially easier.  There are far too many possible system setups.  Any code you come up with for trying to install packages on all the different systems is going to be so complicated that I don't think its worth it. Just ubuntu alone has a couple ways (self-compiled, PPA, downloaded from bitcoin.org)

[etotheipi]

FYI --  I just started a bounty thread for Armory on OSX.

If you are on this thread and want to see someone finally put together the OSX package for it, please donate!

https://bitcointalk.org/index.php?topic=151313.0

[etotheipi]

This is mostly directed at Red Emerald since he has compiled this many times before, but of course anyone can answer:

For the auto-bitcoind-management, I need OSX versions of bitcoind to be compiled and distributed with the download from www.bitcoin.org.  Gavin said that he doesn't do this because there's no clear path to do it, and there's no demand -- except from me.  He would probably be persuaded if I gave him a working build script for it that does exactly what he wants, but hell if I know how to do that.

He says it's not straightforward, because bitcoind is a terminal app, which means putting it in a .app package is not good, and would have to be distributed as a separate package which is extra work for him.  He would create a standalone bitcoind, but it would require all the dependencies to be static-compiled in, which he also says will be a lot of work.  If that was done, I don't know if it could be bundled along with the Bitcoin-Qt .app file.  If we could have a standalone-static-compile-everything bitcoind that would fit into his existing makefile and simply bundle it along with the Bitcoin-Qt .app, that would be absolutely ideal.  I bet he'd be willing to do it -- perhaps 30 minutes of reviewing the makefile, and that's it.  This assumes that it works, and every failed attempt is more "favors" spent ... I'm sure Gavin wouldn't mind spending a few minutes supporting this, but not more than a few minutes...

Any ideas for how to go about this?  How about a static-compiled version of it that doesn't have any dependencies?  I could float a separate .app package by him, but I doubt he wants to add that to his build/release process which is probably annoyingly long already (I know from experience).

[Red Emerald]

Ill look into it. I've been content with my brew formula, but it would be nice if it could be bundled with bitcoin-qt again.

[etotheipi]

<gavinandresen> if you find a simple fix for the makefile.osx so I can make -f makefile.osx RELEASE=1  … and end up with a bitcoind that runs on everybody's machines, then I'd be happy to do that
<gavinandresen> I guess it would be RELEASE=1 STATIC=1 ....
<gavinandresen> I'm compiling RELEASE=1 STATIC=1 on my build machine now, I'll upload the binary for you to play with. I don't remember what the issues were last time...
<gavinandresen> http://skypaint.com/bitcoin/bitcoind.osx

[/font]

It sounds like there is not a deterministic way to build on OSX, so it won't require messing with gitian.   Is it possible to compile and include extra executables in the .app?  Will I be able to reference it by a direct path name?  (i.e.  /Users/LibraryApplications/whatever/bitcoind)

Given the high price of BTC these days, it looks like I only need to offer, say, 3 BTC as an incentive for this one  Again, it's something I have no experience with, but may be "easy" (easier) for others.

[picobit]

The main problem is that no-one can be sure where the user installs Bitcoin-Qt.  Sure, it is most likely to go in /Applications/Bitcoin-Qt.app, but a user may choose to install it anywhere ($HOME/Applications or $HOME/Desktop would be likely candidates).  This makes placing a command-line executable inside the .app directory a bit awkward.

There is a "correct" way to do it, but I doubt you can sell it to Gavin Andresen:  Several apps that have command-line tools (The Aquamacs editor and Xcode come to mind) have a menu point called "install command-line tools" that then copies or links the tools into /usr/bin.  But not only does the app need to have this menu point, it should also have code detecting when it has been updated so it can pop up a dialog requesting permission to upgrade the command line tools.  Clearly some work to implement.

Another "correct" way is not to distribute Bitcoin-Qt as a simple app that is dragged into the application folder, but to use an installer. Again extra work, and I have no clue how to do that.

A simple possibility might be to include bitcoind in an "Extras" folder in the installation disk image, so interested parties (Armory users) can open that folder, where they find bitcoind and a link to /usr/bin so they can drag it over.  I suppose this would work.

Finally, Armory could have a heuristic for locating Bitcoin-Qt and then find bitcoind in a subfolder there.

[ErebusBat]

You could also just ask the user if it is in a non standard location.  If the user has put it somewhere else then they will know where.

[etotheipi]

The main problem is that no-one can be sure where the user installs Bitcoin-Qt.  Sure, it is most likely to go in /Applications/Bitcoin-Qt.app, but a user may choose to install it anywhere ($HOME/Applications or $HOME/Desktop would be likely candidates).  This makes placing a command-line executable inside the .app directory a bit awkward.

Bah!  This is python!  Python can do anything and everything.  It is very fast to search a variety of locations for the executable.  I just need a few of the most common ones and os.walk will take me through the directory trees looking for files that match my criteria.  I can set it to only go 2-3 levels deep and/or stop after 10k files searched, to avoid getting lost. 

And like Erebus said, if that doesn't work...

[ErebusBat]

I would say that there would be two places: /Applications and ~/Applications

However as you know there is no official bitcoind for OSX.  Red Emerald's brew recipe creates a symlink at /usr/local/bin/bitcoind

You could also search $PATH for bitcoind

[itod]

Need some help compiling Armory on Ubuntu 13.10. It exits with:

Code:

g++: error: /usr/lib64/libpython2.7.so.1.0: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/itod/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Sorry if this was answered somewhere, but having browsed through this thread haven't found an answer. Changing two lines in Make suggested in this post
https://bitcointalk.org/index.php?topic=56424.msg1463846#msg1463846
didn't help.

Please suggest a fix. Thanks.

[picobit]

Need some help compiling Armory on Ubuntu 13.10. It exits with:

You might want to repost this in an Ubuntu thread (or create one in the Armory sub-forum).  Since this is a thread about compiling on Mac OS X the Ubuntu or Linux experts are less likely to see it.

[itod]

Need some help compiling Armory on Ubuntu 13.10. It exits with:

You might want to repost this in an Ubuntu thread (or create one in the Armory sub-forum).  Since this is a thread about compiling on Mac OS X the Ubuntu or Linux experts are less likely to see it.

Oh, thanks, came here by Google search and haven't noticed the title. Will do.

[etotheipi]

Need some help compiling Armory on Ubuntu 13.10. It exits with:

Code:

g++: error: /usr/lib64/libpython2.7.so.1.0: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/itod/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Sorry if this was answered somewhere, but having browsed through this thread haven't found an answer. Changing two lines in Make suggested in this post
https://bitcointalk.org/index.php?topic=56424.msg1463846#msg1463846
didn't help.

Please suggest a fix. Thanks.

Agreed this is the wrong thread, but I'll respond quickly.  Did you follow the instructions on the Building Armory from Source webpage?  I just tried it on a stock 13.10 install and it worked.

[itod]

Need some help compiling Armory on Ubuntu 13.10. It exits with:

Code:

g++: error: /usr/lib64/libpython2.7.so.1.0: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/itod/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

Sorry if this was answered somewhere, but having browsed through this thread haven't found an answer. Changing two lines in Make suggested in this post
https://bitcointalk.org/index.php?topic=56424.msg1463846#msg1463846
didn't help.

Please suggest a fix. Thanks.

Agreed this is the wrong thread, but I'll respond quickly.  Did you follow the instructions on the Building Armory from Source webpage?  I just tried it on a stock 13.10 install and it worked.

Yes, followed those instructions. Just found your advice to try the testing branch instead of master, will try latter today and let you know what happened.

[itod]

Once again sorry for the off-topic, but just to report that testing branch compiled OK. Hope these changes will soon be included in master.