Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Yes, I use my super old mac mini and it works like a charm.
Topic: [ANN] The first Armory-for-OSX Release! (Testing) (Read 4627 times)
Yes, I use my super old mac mini and it works like a charm.
Would appreciate if somebody could check if offline/noblockchain access works or gives errors.
thanks
BeeCoin.
thanks
BeeCoin.
Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Never tried the offline in OSX, I use Ubuntu 10.04 for the offline version.
Thanks for the response, Rampion.
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
I'm running 10.7.x
Does it also work in offline/noblockchain mode?
Just to let you know that I've been thoroughly testing Armory on OSX with flawless results up to know - I just have some display problems (coin control display its a bit screwed), but functionalities are 100% working and stable.
Using OS X 10.8.3 on a 2,53 GHz Intel Core 2 Duo with 8GB of RAM.
Using OS X 10.8.3 on a 2,53 GHz Intel Core 2 Duo with 8GB of RAM.
You might consider doing Red Emerald's brew formula if that's all you want access to. Obviously, it would be better to just have this work, but apparently the dependencies are still not totally standalone/bundled yet.
Thanks for your prompt response, Etotheipi.At this point, just for using the EC Calculator, I will simply run it on Windows within a VM.
In the long run, if OSX glitches have been worked out, I'd be interested in using Armory with more functions.
-BeeCoin.
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
Hi folks
I get the same error message (except the french part ;-) ) on Mac OSX Lion. Any solution for this?
At the moment, I want to use it only as EllipticCurve-Calculator in --noblockchain mode without any BitcoinClient installed.
best regards
-BeeCoin.
You might consider doing Red Emerald's brew formula if that's all you want access to. Obviously, it would be better to just have this work, but apparently the dependencies are still not totally standalone/bundled yet.
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
Hi folks
I get the same error message (except the french part ;-) ) on Mac OSX Lion. Any solution for this?
At the moment, I want to use it only as EllipticCurve-Calculator in --noblockchain mode without any BitcoinClient installed.
best regards
-BeeCoin.
Fwhew! The issues are slowly fading away...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
I can't wait! Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Fwhew! The issues are slowly fading away...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Still problems that need to be cleaned up, but at least the problems people are having have workarounds.
Working on the RAM-reduced, instant-startup upgrades now. The new design will actually remove direct dependence on the blk*.dat files entirely! There's just been way too many problems with it. I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database. And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc. This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.
Might be some time before I iron all of it out, though...
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
I deleted the bitcoin directory, installed a fresh copy of bitcoin-qt 0.8.1 and downloaded the whole block chain.
I can cofirm that Armory is now working perfectly!
Thanks. I just sent via PM. I created a new wallet and repeated the same crash.
.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Can you try restart Armory and do it with a new wallet? Can you decrypt other wallets? I've seen an error like this when the wallet was corrupted. Perhaps it was corrupted immediately, somehow? It will fail on any operation that requires unlocking.
Also, please send me a log file. If the error is what I think it is, it'll have a "Stored public key does not match private key!" error (or something like that).
Thanks for the report.
.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Repeatable Steps:
Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash
or
Click Create Paper Backup
Prompt for password
enter password
crash
OS X 10.8.3
Mac Pro 4,1
Process: python [70016]
Path: /Applications/Armory.app/Contents/MacOS/Armory
Identifier: com.armory.armory
Version:
Code Type: X86-64 (Native)
Parent Process: bash [70015]
User ID: 501
Date/Time: 2013-04-19 11:18:10.814 -0700
OS Version: Mac OS X 10.8.3 (12D78)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
- Notifications are disabled completely. Apparently this solution does not play nicely with Growl. 0.5 BTC to anyone who figures out how to fix it!
I will add 0.5 BTC to this "bounty" to get growl working. I'm sure this would happen after all the bugs are worked out.
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
Thanks for your analysis. Actually, I had problems with my local block chain some weeks ago and already re-downloaded the whole thing. Then I again had problems and switched to Bitcoin-qt 0.7.2 – but there's probably still some faulty data on my computer. An I guess you're right that this is the reason for problems with Armory as well.
I will download the block chain again and I'm looking forward to the next release of Armory. It's simply the best app out there and I really appreciate you working on this!
FWIW the beta OSX client seems to be much faster than the one I compiled from the homebrew packages
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...)
Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work.
(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.
It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah!
People will use it to play Satoshi Dice anyway, so that is only fitting 
Can you send me a log file?
Here's the log from a recent start:
http://snippi.com/s/so03ak4
And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/
I just tried it and unfortunately it never finnishes the inital scanning process (I left it open for 4 hours).
I'm on a brand new iMac with SSD, so I guess it should be done by now.
I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?
Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!
I'm on a brand new iMac with SSD, so I guess it should be done by now.
I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?
Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!
Can you send me a log file? And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
0.7.1 should work. But I'll wait to say any more until I see a log file (etotheipi gmail com)
It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah!
I just tried it and unfortunately it never finnishes the inital scanning process (I left it open for 4 hours).
I'm on a brand new iMac with SSD, so I guess it should be done by now.
I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?
Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!
I'm on a brand new iMac with SSD, so I guess it should be done by now.
I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?
Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!
The sip.so library has the same SHA1, so it has not changed. I would think that a timestamp or something would change when compiling, so perhaps it has not worked. It should be enough to do "brew uninstall sip" before and "brew install --env=std sip" afterwards. On the other hand, now that it looks like it is sip and not pyqt that is the culprit, I am less sure about the --env=std stuff.
Do you have a way to check whether anything really changed? I mean, I tried uninstalling everything, but there's a chance that it didn't do it right. I was thinking of restoring a fresh OSX install to try it, but I forgot to save the fresh-install state. I figured what I did was enough...
Unfortunately, I don't have a system to test on that doesn't work, so the best I can do is try your suggestion, and post the results.
I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything. For some reason, the result is 300 kB smaller... not sure why. But I did it, so you can try it. I have updated the original post here.
Dammit! No difference, it still crashes.I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything. For some reason, the result is 300 kB smaller... not sure why. But I did it, so you can try it. I have updated the original post here.
Well, if you can't fix the problem, document it
Some people (probably on older Macs) will find the app crashing - and will have to build it themselves. Certainly not an optimal solution, but the majority that don't see the problem will probably be happy anyway.By the way, it is sip.so that cause the crash, according to Apple's crash reporter. I really cannot see why.
Unfortunately, I don't have a system to test on that doesn't work, so the best I can do is try your suggestion, and post the results.
I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything. For some reason, the result is 300 kB smaller... not sure why. But I did it, so you can try it. I have updated the original post here.
I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything. For some reason, the result is 300 kB smaller... not sure why. But I did it, so you can try it. I have updated the original post here.
@etotheipi:
Could you try adding --env=std to the brew line installing sip and pyqt, it looks like the "superenv" feature in Homebrew is removing options specifying a more general architecture from the compilation commands. You will have to uninstall pyqt and sip, otherwise the script will not reinstall them.
something like
This is a long shot, but it might work. I could then test the resulting .app and see if it runs.
Could you try adding --env=std to the brew line installing sip and pyqt, it looks like the "superenv" feature in Homebrew is removing options specifying a more general architecture from the compilation commands. You will have to uninstall pyqt and sip, otherwise the script will not reinstall them.
something like
Code:
brew install --env=std cryptopp swig qt pyqt wget
(I have tested that sip and pyqt builds with that option, but I have not tested the rest. I suspect that it is pyqt that is causing the trouble.)This is a long shot, but it might work. I could then test the resulting .app and see if it runs.
I think I am on to something, and have a working hypothesis.
My evidence so far:
I suspect that the problems are caused by one or more of the dependencies (sip or Qt) to be built with optimizations for the actual CPU on which it is built. Older CPUs will then not support one or more instructions in the code. This explains why only some people see the problem (those with older machines) and why it does not depend on the OS version.
To do: find the offending dependency, and fix its Makefile.
My evidence so far:
- My .profile cause the app to work when called from the Terminal, disabling my .profile cause it to crash.
- My .profile cause three libraries to be loaded from /usr/local instead of from etotheipi's app: sip.so, QtCore.so, QtGui.so
- The crash is caused by an illegal instruction.
- My MacBook is almost three years old.
I suspect that the problems are caused by one or more of the dependencies (sip or Qt) to be built with optimizations for the actual CPU on which it is built. Older CPUs will then not support one or more instructions in the code. This explains why only some people see the problem (those with older machines) and why it does not depend on the OS version.
To do: find the offending dependency, and fix its Makefile.
I have made a tiny bit of progress. It turns out that on my machine, some libraries are loaded from /usr/local/Cellar which will not be present in normal installations.
I set the environment variable DYLD_PRINT_LIBRARIES to 1, that causes the dynamic loader to print the path of all libraries loaded to stderr, and then I started Armory from a terminal (that, by the way, prevents the crash, and fonts are slightly different, so something must be subtly different). In any case, a long list of libraries appears, and at the end these suspicious lines:
EDIT: Removing .profile cause it to crash in the Terminal too. The self-build one still does not crash. This is the error message:
I set the environment variable DYLD_PRINT_LIBRARIES to 1, that causes the dynamic loader to print the path of all libraries loaded to stderr, and then I started Armory from a terminal (that, by the way, prevents the crash, and fonts are slightly different, so something must be subtly different). In any case, a long list of libraries appears, and at the end these suspicious lines:
Code:
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqgif.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqico.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqjpeg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqmng.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqsvg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtSvg.framework/Versions/4/QtSvg
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtXml.framework/Versions/4/QtXml
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtga.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtiff.dylib
These should certainly not be loaded from there! They don't appear to be included in the app. It could be some optional stuff that Qt loads if it finds it, explaining the strange crashes. Perhaps including them in the app would help.dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqico.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqjpeg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqmng.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqsvg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtSvg.framework/Versions/4/QtSvg
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtXml.framework/Versions/4/QtXml
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtga.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtiff.dylib
EDIT: Removing .profile cause it to crash in the Terminal too. The self-build one still does not crash. This is the error message:
Code:
./MacOS/Armory: line 5: 925 Illegal instruction: 4 bin/python armorybuild/ArmoryQt.pyc
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
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
So, in theory DYLD_LIBRARY_PATH isn't the right way to accomplish this sort of thing -- you're supposed to be able to embed library paths in the executable so that it knows where to look to load the right ones.
In practice I don't know how to do this, or what I'm talking about.
In practice I don't know how to do this, or what I'm talking about.
Hmm, it does not look like otool respects the DYLD_LIBRARY_PATH variable that the driver script uses to cause loading from within the app bundle. I will look more at this tomorrow, I guess reading my previous post makes it pretty obvious that I am too tired for this
So I will note also that if you 'otool -l' the .Python in the app, which appears to be the python library, you get (among other things):
Load command 8
cmd LC_VERSION_MIN_MACOSX
cmdsize 16
version 10.8
sdk 10.8
So that makes me suspect this might be the reason it crashes on less than 10.8? But I'm not sure why that would produce a segfault, so there may be multiple issues.
Load command 8
cmd LC_VERSION_MIN_MACOSX
cmdsize 16
version 10.8
sdk 10.8
So that makes me suspect this might be the reason it crashes on less than 10.8? But I'm not sure why that would produce a segfault, so there may be multiple issues.
OK, here is the list of which shared objects the shared objects in the app depend on, discovered with (and similar for *.dylib). Here is the result, it looks mostly harmless EDIT: It looks like a lot of Qt stuff is loaded from /usr/local instead of from the App itself. So if we do not have the same Qt, it will probably break - but it looks like we do have the same, strange.
I did the same with the self-built version. There were two differences, the version number of /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation that psutils expect (version 744.12.0 in your app, 744.18.0 in the version that I built myself.) And the app you built contains both ./Dependencies/libpng15.15.dylib and ./MacOS/armorybuild/Armory.app/Contents/Dependencies/libpng15.15.dylib whereas the one I built only contains the former.
I have really no idea what this means - I will investigate
EDIT: Dependency on /usr/local/lib/QtGui.framework/Versions/4/QtGui and one more looks bad, bad, bad!
EDIT 2: Everything in this post is dubious, since the correct environment for loading dynamic libraries was not set. I will try again after getting some coffee
Code:
otool -L `find . -name '*.so'`
Code:
./MacOS/armorybuild/_CppBlockUtils.so:
../_CppBlockUtils.so (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.2)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
./MacOS/lib/python2.7/site-packages/_psutil_osx.so:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.12.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/_psutil_posix.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/phonon.so:
/usr/local/lib/phonon.framework/Versions/4/phonon (compatibility version 4.4.0, current version 4.4.0)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/Qt.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtCore.so:
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtDeclarative.so:
/usr/local/lib/QtDeclarative.framework/Versions/4/QtDeclarative (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtScript.framework/Versions/4/QtScript (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtSvg.framework/Versions/4/QtSvg (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtSql.framework/Versions/4/QtSql (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtXmlPatterns.framework/Versions/4/QtXmlPatterns (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtDesigner.so:
/usr/local/lib/QtDesigner.framework/Versions/4/QtDesigner (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtScript.framework/Versions/4/QtScript (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtXml.framework/Versions/4/QtXml (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtGui.so:
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtHelp.so:
/usr/local/lib/QtHelp.framework/Versions/4/QtHelp (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtSql.framework/Versions/4/QtSql (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtMultimedia.so:
/usr/local/lib/QtMultimedia.framework/Versions/4/QtMultimedia (compatibility version 4.8.0, current version 4.8.4)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtNetwork.so:
/usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtOpenGL.so:
/usr/local/lib/QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtScript.so:
/usr/local/lib/QtScript.framework/Versions/4/QtScript (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtScriptTools.so:
/usr/local/lib/QtScriptTools.framework/Versions/4/QtScriptTools (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtScript.framework/Versions/4/QtScript (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtSql.so:
/usr/local/lib/QtSql.framework/Versions/4/QtSql (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtSvg.so:
/usr/local/lib/QtSvg.framework/Versions/4/QtSvg (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtTest.so:
/usr/local/lib/QtTest.framework/Versions/4/QtTest (compatibility version 4.8.0, current version 4.8.4)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55179.1.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtWebKit.so:
/usr/local/lib/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.9.0, current version 4.9.3)
/usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtXml.so:
/usr/local/lib/QtXml.framework/Versions/4/QtXml (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/PyQt4/QtXmlPatterns.so:
/usr/local/lib/QtXmlPatterns.framework/Versions/4/QtXmlPatterns (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.4)
/usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/sip.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/twisted/python/sendmsg.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/twisted/runner/portmap.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/twisted/test/raiser.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/lib/python2.7/site-packages/zope/interface/_zope_interface_coptimizations.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./Dependencies/libpng15.15.dylib:
/usr/local/lib/libpng15.15.dylib (compatibility version 30.0.0, current version 30.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
./MacOS/armorybuild/Armory.app/Contents/Dependencies/libpng15.15.dylib:
/usr/local/lib/libpng15.15.dylib (compatibility version 30.0.0, current version 30.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
I did the same with the self-built version. There were two differences, the version number of /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation that psutils expect (version 744.12.0 in your app, 744.18.0 in the version that I built myself.) And the app you built contains both ./Dependencies/libpng15.15.dylib and ./MacOS/armorybuild/Armory.app/Contents/Dependencies/libpng15.15.dylib whereas the one I built only contains the former.
I have really no idea what this means - I will investigate
EDIT: Dependency on /usr/local/lib/QtGui.framework/Versions/4/QtGui and one more looks bad, bad, bad!
EDIT 2: Everything in this post is dubious, since the correct environment for loading dynamic libraries was not set. I will try again after getting some coffee
Yes, I think we can, with otool -L. I will give it a try, and whether successful or not I will report back here.
Maybe someone with more lower-level tracing experience than me can help out: can we trace the dependencies used by the .app I created? It's supposed to be completely self-contained, but it sounds like there's still some system libraries being accessed, some of which are not compatible with the ones in my VM.
OK, if I build the app myself, it works.
If I download the app you built to my laptop, it crashes.
If I download it to my wife's macbook, it works just fine. It can even print paper backups! (which has not worked on my laptop since multithreading appeared)
I guess it has something to do with conflicting versions of something that I have installed - I have installed all kinds of junk on this machine for some time now. I will investigate further tonight or tomorrow, have to run now.
If I download the app you built to my laptop, it crashes.
If I download it to my wife's macbook, it works just fine. It can even print paper backups! (which has not worked on my laptop since multithreading appeared)
I guess it has something to do with conflicting versions of something that I have installed - I have installed all kinds of junk on this machine for some time now. I will investigate further tonight or tomorrow, have to run now.
I checked the Mac app on my Mountain Lion 10.8.3 MacBook Pro.
Unfortunately, it is highly unstable. The app crashes almost no matter what I try to do. For example, I have a testing wallet with no encryption. Clicking on Make Paper Backup cause a crash, also if bitcoin-qt is not running.
I tried to build from source, that version works, but it is clearly a different version. The app is 0.87.98, the one I build from source is 0.87.3. Probably I am building from the wrong branch, which branch should I build to test this? I was planning to test if it is the build or the armory version that is unstable by building myself (all previous versions that I have built from source have been rock stable). If it is the app only, I could also modify the makefile to build with debugging enabled, and attach a debugger (although debugging a multhithreaded program is new for me).
In any case I am busy at work, so my progress may be slow.
Unfortunately, it is highly unstable. The app crashes almost no matter what I try to do. For example, I have a testing wallet with no encryption. Clicking on Make Paper Backup cause a crash, also if bitcoin-qt is not running.
I tried to build from source, that version works, but it is clearly a different version. The app is 0.87.98, the one I build from source is 0.87.3. Probably I am building from the wrong branch, which branch should I build to test this? I was planning to test if it is the build or the armory version that is unstable by building myself (all previous versions that I have built from source have been rock stable). If it is the app only, I could also modify the makefile to build with debugging enabled, and attach a debugger (although debugging a multhithreaded program is new for me).
In any case I am busy at work, so my progress may be slow.
Ack. Not good! It seems to be random, when it works and when it doesn't (not by OSX version).
If you want to do further testing, use the "testing" branch. Only the blockdata access stuff is multi-threaded...everything else runs in a single thread. I don't think it should be too bad.
I checked the Mac app on my Mountain Lion 10.8.3 MacBook Pro.
Unfortunately, it is highly unstable. The app crashes almost no matter what I try to do. For example, I have a testing wallet with no encryption. Clicking on Make Paper Backup cause a crash, also if bitcoin-qt is not running.
I tried to build from source, that version works, but it is clearly a different version. The app is 0.87.98, the one I build from source is 0.87.3. Probably I am building from the wrong branch, which branch should I build to test this? I was planning to test if it is the build or the armory version that is unstable by building myself (all previous versions that I have built from source have been rock stable). If it is the app only, I could also modify the makefile to build with debugging enabled, and attach a debugger (although debugging a multhithreaded program is new for me).
In any case I am busy at work, so my progress may be slow.
Unfortunately, it is highly unstable. The app crashes almost no matter what I try to do. For example, I have a testing wallet with no encryption. Clicking on Make Paper Backup cause a crash, also if bitcoin-qt is not running.
I tried to build from source, that version works, but it is clearly a different version. The app is 0.87.98, the one I build from source is 0.87.3. Probably I am building from the wrong branch, which branch should I build to test this? I was planning to test if it is the build or the armory version that is unstable by building myself (all previous versions that I have built from source have been rock stable). If it is the app only, I could also modify the makefile to build with debugging enabled, and attach a debugger (although debugging a multhithreaded program is new for me).
In any case I am busy at work, so my progress may be slow.
lots of testing today on both mac (online) and ubuntu (offline)
mac is the release from this this thread on 10.7.5 osx
ubuntu is on 10.04 using 0.86.3-beta dependencies bundle
backups importing and exporting cd/usb copies
recovering from paper wallets
sending online/offline transactions
all checks out as far as i can tell
mac is the release from this this thread on 10.7.5 osx
ubuntu is on 10.04 using 0.86.3-beta dependencies bundle
backups importing and exporting cd/usb copies
recovering from paper wallets
sending online/offline transactions
all checks out as far as i can tell
In fact I first download and unzip Armory_OSX_0.87.98.zip
I get an Armory.app file and drag it to /Applications directory
I double-click on this file... icon was jumping 3 times and disappear
(because of segfault)
so I run a console to run it and
is console stderr
I also tried
But there is no directory named Armory...
so segfault appears before creating log file
I also tried with --offline flag
I get an Armory.app file and drag it to /Applications directory
I double-click on this file... icon was jumping 3 times and disappear
(because of segfault)
so I run a console to run it and
Code:
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 62302 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
I also tried
Code:
$ open ~/Library/Application\ Support/Armory
The file /Users/scls/Library/Application Support/Armory does not exist.
But there is no directory named Armory...
so segfault appears before creating log file
I also tried with --offline flag
Code:
/Applications/Armory.app/Contents/MacOS/Armory --offline
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 734 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
Hello,
thanks for this public OS X release but I get a segfault
I'm using Mac OS 10.7.5 with a Macbook Air
thanks for this public OS X release but I get a segfault
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
I'm using Mac OS 10.7.5 with a Macbook Air
Code:
$ python -V
Python 2.7.3 -- EPD 7.3-2 (64-bit)
Can you try running it with " --offline" at the end, to see if it loads without any blockchain stuff?
Was there a log file created by Armory in your ~/Library/Application Support/Armory directory?
Unfortunately, I hope someone with more OSX experience will be able to investigate these problems. It looks like you're using a French OS, which makes me realize I never tested unicode support on OSX... I guess I should take a shot at that...
Hello,
thanks for this public OS X release but I get a segfault
I'm using Mac OS 10.7.5 with a Macbook Air
Kind regards
thanks for this public OS X release but I get a segfault
Code:
$ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée]
I'm using Mac OS 10.7.5 with a Macbook Air
Code:
$ python -V
Python 2.7.3 -- EPD 7.3-2 (64-bit)
Kind regards
awesome about offline ready
will be using ubuntu for the offline version though!
mac for online/bitcoin-qt - offline just armory
yeah it's got a ssd, cpu is a i7 quad 2.4 and 8gb 1600mhz ram
out for the night but i'll be doing all kinds of back and forth online mac > offline ubuntu transactions / back ups / restores. will let you know if i run into any trouble
anything specific you can think of i should check?
will be using ubuntu for the offline version though!
mac for online/bitcoin-qt - offline just armory
yeah it's got a ssd, cpu is a i7 quad 2.4 and 8gb 1600mhz ram
out for the night but i'll be doing all kinds of back and forth online mac > offline ubuntu transactions / back ups / restores. will let you know if i run into any trouble
anything specific you can think of i should check?
latest pro retina stock. instant open and scanning of blockchain took 3 minutes
guess i need to quit being lazy and get the parts for the offline system build put together
with the latest bitcoin-qt
looks be using 1.8 gb of ram not so bad
guess i need to quit being lazy and get the parts for the offline system build put together
with the latest bitcoin-qt
looks be using 1.8 gb of ram not so bad
Oh, I didn't even realize that this packaging job is offline-bundle-ready! Since it's completely self-contained, you should be able to use it on a freshboot of an offline OSX installation. Cool!
3-minute blockchain scan is good! Are you using an SSD?
latest pro retina stock. instant open and scanning of blockchain took 3 minutes
guess i need to quit being lazy and get the parts for the offline system build put together
with the latest bitcoin-qt
looks be using 1.8 gb of ram not so bad
guess i need to quit being lazy and get the parts for the offline system build put together
with the latest bitcoin-qt
looks be using 1.8 gb of ram not so bad
Hmm... it takes 4-5 minutes on my OSX VM in VMware, with 4 GB of RAM. I wonder if maybe it's a caching problem? Weird.
Well now that I'm done with this, I'll finally be able to get to the persistent blockchain stuff. So RAM usage will drop, and full scans should only happen on the first sync, and during import/sweep. I have no idea how long it's going to take, but I do know exactly how I'm going to do it.
Well now that I'm done with this, I'll finally be able to get to the persistent blockchain stuff. So RAM usage will drop, and full scans should only happen on the first sync, and during import/sweep. I have no idea how long it's going to take, but I do know exactly how I'm going to do it.
The only issue I had was the time, it start at 3 mintues it took around 30-40mins to load the blockchain.
Great work!
Great work!
What's the system specs? 30-40 min is excessive....
The only issue I had was the time, it start at 3 mintues it took around 30-40mins to load the blockchain.
Great work!
Great work!
What's the system specs? 30-40 min is excessive....
The only issue I had was the time, it start at 3 mintues it took around 30-40mins to load the blockchain.
Great work!
Great work!
It finally works! Thanks again to higuys who debugged and polished his OSX build script, which makes building on OSX too easy. In fact, it was so easy, I did more than I had to and ended up breaking it. Whoops!
But it's all sorted out now, and I've been playing around with it in my OSX VM. I can see that there's a lot of stuff that needs improvement, but it does appear to be very usable. I had to completely disable Bitcoin-Qt/bitcoind management, because there is no reliable way to get bitcoind, and I'm not sure yet if I want to run Bitcoin-Qt. I might have no choice...
I used my online GPG to sign this just to have something. My offline system is not setup yet for certificate-signing OSX builds. But I have a feeling this will need some tweaking before v0.88-beta anyway.
https://bitcointalksearch.org/topic/m.1655941
NOTES:
But it's all sorted out now, and I've been playing around with it in my OSX VM. I can see that there's a lot of stuff that needs improvement, but it does appear to be very usable. I had to completely disable Bitcoin-Qt/bitcoind management, because there is no reliable way to get bitcoind, and I'm not sure yet if I want to run Bitcoin-Qt. I might have no choice...
I used my online GPG to sign this just to have something. My offline system is not setup yet for certificate-signing OSX builds. But I have a feeling this will need some tweaking before v0.88-beta anyway.
https://bitcointalksearch.org/topic/m.1655941
NOTES:
- I got the icons working.
- Auto-bitcoind/bitcoin-qt is disabled. I may have to start bitcoin-qt instead and minimize it immediately. Anyone know how to start-and-minimize-immediately an OSX app, from the command line?
- Notifications are disabled completely. Apparently this solution does not play nicely with Growl. 0.5 BTC to anyone who figures out how to fix it!
Jump to: