Topic: Armory - Discussion Thread - page 193. (Read 521749 times)

compiling for i686 didn't work, still "illegal instruction" on target system. compiling for i586 did the trick.


I might test it, but since I have a working version now, I'll probably do that after "import v0.6 satoshi wallet.dat" is implemented (unfortunately all wallets I want to import have been touched by newest git satoshi client).

To run from git, you need to switch to the "tablesortingfix" branch.  I will merge the code into master once I'm ready to "release" it.

And yes, I know it's slowing down.  The acceleration of blockchain size has me scrambling to get some major things updated sooner rather than later.  Unfortunately, I'm just not there yet.  :-/

As for "google.com", I also check microsoft.com ...  I don't suppose that helps?  I figured that was a reliable way to determine if you have a connection to the outside world, but I guess it isn't.  Recommendations?

So I'm running the latest git, but it still says .76.  Shouldn't it be .77? It's also always sitting at 98% CPU and being really unresponsive

It looks like you have a check to google.com to see if the network is up.  Problem is, all my connections on this test system are proxied through Tor and sometimes google blocks Tor exit nodes so I get a socket timeout from line 729 of ArmoryQt.py in setupNetworking

Side note: The blockchain loaded in 90 seconds. Outside of a VM (on the host) it loads in about 60.

MMX, SSE, 3DNow!, etc are not instruction sets in their own right, but rather extensions of the standard IA-32 instruction set (this is the common instruction set for x86-32 CPUs). Any code which is compiled to use these extensions will not work on any CPU with an instruction set that doesn't include these extensions. As I understand, it is possible (in assembly) to write two versions of a function (one using the extended instructions and one using the just the standard instruction set) and have the program select which version to use by querying the CPU at runtime, but that's far beyond my level of expertise. Note that this is only possible because these extended instruction sets simply add new instructions without replacing or changing the standard instructions.

Are you sure it works, though? On all IA-32 systems? Unless you're absolutely positive the default is safe, -march=i386 is the only way to be sure. Compiling for any other architecture is very likely to result in a binary that is guaranteed to crash on certain systems.

I actually meant "weighted majority" of CPUs -- I recognize that not all CPUs can use compatible instruction sets.  However, a majority of users are using CPUs that have a common instruction set.  I was under the impression that multiple instruction sets are generally supported on each CPU, hence "SSE", "SSE2", "3DNOW", etc.  Given that I've seen large lists like that on CPU spec pages/boxes before, I suspect it's the case...

Either way, I removed the -march option and it seems to work.  The documentation suggests that gcc will decide for me what to compile, which is not march=native.  Maybe I still have no idea what I'm talking about, but I'm going with what works.  So far the python2.6-i386 works after the change.  Please try the others and let me know.

If you think for a moment about what a CPU is and how it works, you'll realise what you're suggesting makes absolutely no sense. Every CPU has a single instruction set, and cannot use any other. IA-32 (i386) is a subset of all the various instruction sets used in x86-32 CPUs, and that's about a close as you're ever going to get to one instruction set being supported by a majority of CPUs. The instruction sets of other CPUs such as PowerPC, ARM, et al, are all totally incompatible with each other and with IA-32, so there's absolutely no way to compile code so that it works on all of them.

Actually, that may be what broke it in the first place. Specifying the target architecture is mandatory for the above reason. If you don't, the compiler will use the system default, which may not always be what you want. You must always specify what architecture you're compiling for if you want it to work on systems other than your own. I strongly recommend that you use -march=i386 -mtune=generic to avoid any future surprises.

-mtune doesn't actually have anything to do with what instruction set your target architecture uses - instead it just optimises your code for things like the cache size of a particular CPU and so on. Setting it to the wrong CPU (even a CPU that doesn't use the same instruction set as the one you're compiling for) won't ever break anything, but it can have a detrimental effect on your code's performance. Always set it to "generic" unless you have a specific CPU in mind.

I've never cross-compiled either, but yes, that should work. Let me know how it goes.

It works!  (as far as I can tell)

I removed the -march=native option and now my VM compiles .deb packages that work on my offline computer.  I have no idea how or why it worked before, but it makes sense why it works now. 

PLEASE download and test the new version, especially if you were getting that "Illegal Instruction" error.  The links from my previous post are still valid, but copied here again for convenience.

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win32.msi (offline only!)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_amd64.deb  (Ubuntu 11.04+, 64-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_amd64.deb  (Ubuntu 9.04-10.10, 64-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_i386.deb  (Ubuntu 11.04+, 32-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_i386.deb  (Ubuntu 9.04-10.10, 32-bit)

Okay, I just started reading up on it, and I see what's going on.  Doesn't explain why it used to work then suddenly stopped working, but it sounds like was lucky that it ever worked!  Also explains why reverting the changes didn't help.

I see there is no -march=generic option, which is unfortunate because I figured there would be an instruction set that is supported by a majority of CPUs.  It looks like, just not using the -march option at all is what I want, and -mtune=generic. 

Does this also mean that I can use "-march=i386  -m32" to compile the 32-bit binaries on my 64-bit system?  It would be nice to be able to cross-compile, but I never bothered to figure out how, and have a separate VM for each .deb file...

It's not my strong suit either, I just have enough experience with Linux programs whose installation instructions consist entirely of "Run make and fix compilation errors" to have some idea of what I'm doing in that area. First of all, don't use -march=native when compiling binaries for general distribution! I don't know about Ubuntu, but most "32-bit" distros these days actually use the P6 architecture instead of i386, which has the advantage of allowing you to use up to 64GB of RAM with a supposedly 32-bit CPU, but the disadvantage that code compiled for such a system will flat out not work on a true 32-bit system. You should be using -march=i386 for IA-32 and -march=k8 (er, I think...) for AMD64 (as well as -mtune=generic, though omitting it won't cause any errors, but may (or may not) have an effect on performance). That should at least fix the "Illegal instruction" issue, which is almost certainly caused by accidentally compiling for a CPU-specific architecture.

Makefiles and compiling issues are not my strongest skillset.  Perhaps you can help me/us figure out what the problem might be...?  I'm about to revert the crypto++ updates made in 0.76 to see if that resolves the issue.  That will cause anyone using gcc 4.7+ to no longer be able to compile it, but I suppose I can maintain a gcc4.7 branch that follows the master with only the changes needed.

So, any recommendations?

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

What didn't work well?  The new binary installer that I posted?  Or compiling for i586/i686?  I think the new .deb file I posted should work on other 32-bit linux systems, and if it doesn't, I really don't understand what's going on.

I'm super curious why the 32-bit-binaries-compiled-on-my-VM used to work but now they don't...?  There was a very minor change made to the crypto++ library to make it work with the latest gcc, but that was just adding "this->" references to some calls.  Perhaps the behavior actually changed... I'll have to revert the crypto++ library and see if my VM can compile working code again...

didn't work (illegal instruction)

I then tried with -march=i586 and after solving some other issues, like "forcing" to link against python2.6 (target system has python 2.6, build system 2.7).

It now works, no more "illegal instruction" when creating a wallet.

I just recompiled the 32-bit version on one of my physical machines running Ubuntu 32-bit (luckily, I have a lot of them!).  I don't have one for 12.04-32bit, but I guess I can make it happen if necessary.  Or maybe someone can help me figure out how I should be compiling crypto++ to avoid this problem.  The 'march=i?86" options sound kind of promising except I don't want to battle the crypto++ library too much... it's not my library, I don't want to mess with it...

Anyways, here's the updated armory_0.77_python2.6_i386.deb.  I tested it on my offline system and it worked.  Hopefully it will work for others, too.

what parts are you compiling? cpp4Swig?

just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.

I'm about to test... with "-march=i686", but other problems pop up.

Actually, I just ran into this the other day, too.  I don't know why it used to work and now it doesn't.  I have been compiling the binaries on Ubuntu VMs and it seems that the 32-bit systems are creating bad binaries.  Perhaps the CPU type of a 32-bit VM is "different"?   Anyone have any problems with the 64-bit packages?

I'll investigate this a little more thoroughly.  For now, I'll just compile it on a physical 10.04 32-bit system I have.  At least, the python2.6 package can be done there...

I'm experiencing the "Illegal instruction" problem on my first-gen asus eeepc.

It seems to be an invalid instruction in the binary (I used the dependency bundle).

Ran an strace and it seems to be in the random number generator somewhere (I can't see an actual stacktrace, how do I dump one).

So I guess one of the dependency libs might've been compiled for a different CPU.

Ideas anyone?

I did restart the satoshi client, that must be what happened. Thanks for your time

I'm not sure why that worked.  I would think that issue is that the Satoshi client already added the tx to its own memory pool, and "broadcast it" once, and then won't broadcast it again.  And any tx conflicting with that one will be rejected.  Thus, you would need to clear the Satoshi-client memory pool in order to execute any more transactions with that wallet (at least any tx using any inputs used by the first tx).

I would expect that maybe the tx you finally sent used different inputs, or maybe you restarted the Satoshi client which might purge the memory pool of tx that aren't relevant to its own wallet (I don't know if it actually does that though...)

Nevermind, I found the trick: delete the user folder and reimport the armory wallet