[tahoe-dev] 1.9.1 on really old machine

[Zooko Wilcox-O'Hearn]

Hello Dmitriy Kazimirov:

Thank you for the bug report.

On Mon, Feb 6, 2012 at 9:20 PM, Dmitriy Kazimirov
<dmitriy.kazimirov at viorsan.com> wrote:
>
>  File
> "/root/allmydata-tahoe-1.9.1/Twisted-10.2.0-py2.4-linux-i686.egg/twisted/conch/ssh/keys.py",
> line 17, in ?
>    from Crypto.Cipher import DES3
> exceptions.ImportError:
> /root/allmydata-tahoe-1.9.1/support/lib/python2.4/site-packages/pycrypto-2.4-py2.4-linux-i686.egg/Crypto/Cipher/DES3.so:
> wrong ELF class: ELFCLASS64

I think this means that the DES3.so shared lib is compiled for 64-bit
and the system is 32-bit-only. You can confirm by running

objdump -a -f DES3.so

Please let us know what it says. I think it will say something about
"architecture: i386:x86-64".

Now if that's the problem, then the question is how that 64-bit .so
got into a binary Python package (.egg) which is supposed to be for
32-bit systems. as you can tell from the name of the .egg:
pycrypto-2.4-py2.4-linux-i686.egg . Where did the setup.py file get
that .egg from, I wonder? It must have gotten it from our repository
of hosted eggs:
https://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/README.html

Okay, I'm downloading the .egg from there:
https://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/pycrypto-2.4-py2.4-linux-i686.egg

Aha! Yep:

$ objdump -a -f ./Crypto/Cipher/DES.so

./Crypto/Cipher/DES.so:     file format elf64-x86-64
./Crypto/Cipher/DES.so
architecture: i386:x86-64, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0000000000001200

Okay, I've removed that incorrect pycrypto-2.4-py2.4-linux-i686.egg
from our tahoe-lafs-dep-eggs repository. The next time you, or anyone
with Python 2.4 and 32-bit linux, tries to build Tahoe-LAFS, they
should get a different problem. :-) Please post if you do.

Regards,

Zooko