DYLD_LIBRARY_PATH tells the dynamic linker (dyld) to look in the specified places for libraries before it tries the locations in the binary headers and subsequently crashes because it can't find anything. It makes sense then that otool doesn't tell you where the libraries that are actually being used are coming from, as this is being done at runtime and requires no static changes to the binaries. You could set the correct places in the binaries, but you're going to have to edit the build configuration for qt and anything that uses those dependencies. Imo that's not going to change anything and you'll just spend time pulling your hair out.

I don't know what the problem is for everyone since there's only one post with actual error output and it's a segfault. I can't debug that without being able to reproduce it.

If it is trying to find more libraries installed globally that aren't there, you should get an error saying so. If this is the case it's not a big deal, and it can be fixed. I really don't think it is, though, as this would have come up again at some point in the past month.

I suspect some of the problems are coming from the fact that the minimum OS X version is set to 10.8 in the python executable, since etotheipi is building on 10.8.

You can do a search/replace with a hex editor on any binaries you think have a minimum version set like so:
Search: 24 00 00 00 10 00 00 00 00 08 0A 00 00 08 0A 00
Replace: 24 00 00 00 10 00 00 00 00 06 0A 00 00 06 0A 00

This will change the minimum version from 10.8 to 10.6

Right, I can't for the life of me get a snow leopard VM set up, so I'm going to need some more information. There has to be some error output.

I'm working on making a Snow Leopard VM so I can test this. I think I know what the problem is, though. Does your computer have a 32-bit only processor (Core Duo)?

Nothing's stopping you from joining the channel. irc.freenode.com #bitcoin-armory

I also told him how to recreate what I did, which is what he meant by recipe. The app was just proof.

You shouldn't have to install anything, and afaik all of the dependencies are bundled. Running the Armory executable doesn't even output any errors? That's strange. It seems almost everyone is on 10.8.x, so I'll have to set up a 10.6 and 10.7 VM to test more.

If you do use the .app, you don't have to worry about uninstalling the old one. Everything that's needed is contained within the .app.

I know you should "never say never", so to speak, but the .app is the exact same thing as what was used before, just self-contained. I tested the basic features myself, making transfers, creating wallets, etc. Of course you should take that with a grain of salt, but that's what I have to say...

Here's my final proof of concept app: http://goo.gl/UYBEj

Feel free to report any more problems, I think I weeded everything out though. I'm glad you guys found my work useful.

Alright, with the help of some pills, I fixed most of the stupid shit that my script did. Now, you only need pyqt installed with brew, and it'll just copy it and sip over to the environment. It's still a bit dirty, but it's better.

I'm also integrating it with the makefile in the Armory root dir. So, all you'll have to do is run make osx, and it'll spit out an Armory.app in an osxbuild dir.

What network?

Of course it's in the instructions, at first I was under the impression that pyqt was just needed at runtime, not for building. By the time everything was working I was rather tired and didn't feel like rewriting a good portion of it plus doing MORE testing just to remove that part, such is life.


It is because of what you said. I'm well aware they're unnecessary, but I'm not able to go through the whole gambit of fixing and testing right now. If you figured it out, that's great. Once I get over this damn flu I'll try to make it less gross, or you can fork that gist, I don't care. I should probably reiterate that this script was in no way intended for production use. I mean, it would work, but it was just intended to be a proof of concept.

Oh, and I'd like to point out that it doesn't actually need any changes. The configure.py file has some handy --bindir, --destdir and --sipdir options.

Is there are IRC channel for Armory or something like it? I'm tired of constantly checking the forum, live chat would be much easier.

It seems you need pyqt to make Armory, and it's also obviously needed inside the bundle. Not optimal, sure, but I was having trouble getting it to work otherwise.

Signing is easy. Once you have your cert you'll do codesign -s identity Path_to.app, easily scripted. You can check that it signed by making sure the _CodeSignature dir exists inside Contents.

You can add an icon to the app easily, too. It won't really do anything when Armory is running though, since python is a separate task. All you have to do is make an icns file (you can convert a png or something into one), put it in a Resources dir inside Contents of the app, and then add a CFBundleIconFile key to the Info.plist, the value being the name of the icns file (minus extension). By task tray I think you mean the dock, users choose what goes in that. If referring to the menu bar (at the top), then yes, the icon is there while running.

Thanks for reminding about bitcoin-qt, turns out I was on a super old version!

Cool, is there a way to merge gists? I think I'll add codesigning later, once I better integrate it with the Armory source.

You'd have to modify the script a bit for what you want, especially if it's going to be in the makefile. I might play around with that later this week, I'll send you a pull request on github if I get any results.

The final app is about the same as my last version, 134.7MB for the actual app, 38.4MB zipped. Apps are almost always distributed in a zip or dmg, imo zip is better. Dmg doesn't really have any benefit other than being shiny.

Here's an app generated by the script: http://goo.gl/GWeoO

Alright guys, the script is done. I've tested it a few times and the .app it produces appears to work fine. None of the problems people have had before are present (afaik). I still can't test making transfers or anything like that, but I don't think the wrapper would affect it. How long is syncing the blockchain supposed to take for the first time?

Once again, download the buildarmory.sh file from https://gist.github.com/bsmt/5130568 and run it. You'll have to input your password a few times (unless you run it as root) and say "yes" to one license agreement. The dependencies it needs to run are xcode, brew, and pip. Aside from that, it will install cryptopp, swig, qt, pyqt and wget on your machine. It takes a while to build because it does everything from scratch and pyqt takes a looooooong time to make. There are some optimizations that could be made, but I'm going to hold off until I get feedback from etotheipi and everyone else.

It might be a good idea to integrate this into the Armory makefile, too, provided this is what etotheipi wants.

Thanks, I've fixed problem 1 and 3 already. I'm now testing and then I'll update the gist.

Swig isn't a python package just like you said, so it doesn't matter if you're in an env or using global python. You should be able to use it anywhere.

Using brew isn't going to make it system-dependent. You're installing those so that you can either build armory or put qt into the package. In the end the only things going into the actual package are qt, some python packages installed in the env, python, and armory

Looks like the problem isn't where swig is installed, but that it can't find some files. I'm not sure what you're trying to do with the Lib folder from the env either...

All you should have to do is install swig with brew, though you also need cryptopp and qt as shown by WyseNynja's guide. I don't see how global python is getting confused with the virtualenv, you have to do bin/python, bin/pip etc in the directory to use the virtualenv. Logs would be awesome.

As for the script, I decided to have it just install swig, cryptopp, qt and virtualenv for you. Now all that's required is brew and pip, which you should have anyways.

Terminal output? Also, what version did you try? I've had to fix it three times already.

I forgot to put License.pyc file in! Weird that it shows the path to my hard drive...

I just tested it on my macbook that hasn't run Armory before, and it worked. I could still be missing dependencies though.

Anyways, revision 3: http://goo.gl/73v3b

Thanks for being patient with me guys.

That is strange... Looks like I missed some settings files, or something.