Topic: Building Armory on OSX - page 8. (Read 32281 times)

They worked for me on both.

anyone know if the lion instructions work on mountain 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

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

New and improved instructions for 64-bit Lion!


Now edit the DEPSDIR and STATICPYTHON in cppForSwig/Makefile


Almost there!

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.

PKG files are installers, just like windows they scripts to install a program. A .dmg should contain an .app file which is all that is need to run the program and that should be moved to your application directory.

You need xcode to get GCC compiler and xcode is developer tools. Brew is a ruby program to get other linux programs to install on mac and run. They are completely different things. I think 32-bit in Mac OSX is phased out, but I am using a snow leopard on a 32bit machine.

I think you could use python to install it but the real way would be to use a pkg script installer.

I really can't wait for an armory build js

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

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.

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.

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.

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

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.

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.

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.


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


But that fails with:


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)


I also had to edit the makefile


And then its just a little bit of waiting

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


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

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

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.

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

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

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

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


Then I get a wall of


then


However...


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.

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.


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.

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

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

And Armory depends on bitcoind, right?

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.

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:  [email protected].  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?