Firstly, apologies for Outlook and its inability to format responses in a conventional or easy to follow way; it's an embarrassment, but unfortunately these are the tools that poor corporate serfs have to work with.
Secondly, thanks for both these suggestions: they're both worth trying. I shall report back if I have any success. -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: 18 January 2012 11:37 To: openssl-users@openssl.org Subject: Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36) On 1/18/2012 12:00 PM, Brooke, Simon wrote: > Hi > > We have a box running Debian 2.1 still in production, and for complicated > reasons we can't replace it immediately. I'm trying to compile OpenSSH for > it, and to do that I need to compile OpenSSL. The issue I'm seeing is very > similar to that reported by Alain Guibert here: > http://permalink.gmane.org/gmane.comp.encryption.openssl.devel/10800 but I > cannot find whether his issue was ever resolved. > > Essentially, the machine appears to be a i386 (although the Bogomips value > seems suspiciously high): > > $ more /proc/cpuinfo > processor : 0 > cpu : ?86 > model : 386 SX/DX > vendor_id : GenuineIntel > stepping : 9 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > fpu : yes > fpu_exception : yes > cpuid : yes > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov 16 17 19 21 22 mmx 24 25 26 27 28 29 31 > bogomips : 3185.05 The unknown flag bits indicates that this CPU is more recent than what the /proc/cpuinfo code can actually understand, so the model info is probably bogus. > > Linux kernel is 2.0.36: > $ uname -a > Linux devsys.dunlops.com 2.0.36 #1 Thu Jun 21 16:51:34 GMT 2001 i?86 unknown > > and it appears to know about ELF: > $ file /lib/ld.so.1.9.10 > /lib/ld.so.1.9.10: ELF 32-bit LSB executable, Intel 80386, version 1, > statically linked, stripped Yes, Debian has supported ELF at least since hamm (2.0), possibly even before that (I don't have the history file handy right now). > > Output from make (after doing config) is as follows: > > $ make > making all in crypto... > make[1]: Entering directory `/tmp/simon/openssl-1.0.0f/crypto' > gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall > -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > -DWHIRLPOOL_ASM -c -o x86cpuid.o x86cpuid.s > x86cpuid.s: Assembler messages: > x86cpuid.s:188: Error: bad register name ('%xmm0') > x86cpuid.s:189: Error: bad register name ('%xmm1') > x86cpuid.s:190: Error: bad register name ('%xmm2') > x86cpuid.s:191: Error: bad register name ('%xmm3') > x86cpuid.s:192: Error: bad register name ('%xmm4') > x86cpuid.s:193: Error: bad register name ('%xmm5') > x86cpuid.s:194: Error: bad register name ('%xmm6') > x86cpuid.s:195: Error: bad register name ('%xmm7') > make[1]: *** [x86cpuid.o] Error 1 > make[1]: Leaving directory `/tmp/simon/openssl-1.0.0f/crypto' > make: *** [build_crypto] Error 1 > > This looks to me as though the GCC backend is trying to use the SSE2 > instructions which address the XMM registers, which if I remember my ancient > history weren't present on the i386. > > GCC version is 2.7.2.3 and was installed from a standard Debian package, but > egcc 2.91.60 seems also to be available: > $ dpkg -l | grep gcc > ii egcc 2.91.60-5 The GNU (egcs) C compiler. > ii gcc 2.7.2.3-7 The GNU C compiler. > > Let's be clear: I don't actually /want/ to compile this for the sake of > compiling this, I just want a version of openssh that works; and as this is > essentially industrial archaeology it isn't worth the developers wasting time > making things work on what is essentially obsolete kit. So if anyone has a > working binary either just of the openssl libraries or of all the stuff > needed to support openssh, on an i386 running Linux 2.0.x, I'd be extremely > grateful. But if not, I'd like to know how to get openssl to compile, if > possible. My guess: This is because the slink version of gas (/usr/bin/as) is too old to know about MMX/SSE2 instructions which are compiled but protected by "if" statements checking at runtime if the CPU is good enough. The file name strongly suggests this is the file that does that detection. One workaround would be to setup a separate slink build box (to avoid changing this machine in ways that might break whatever is needing it to stay at slink) in a virtual machine, and then on the build box install a backported/recompiled binutils package based on the latest code from lenny, while keeping the historic gcc and libraries. A simpler method would be to compile a statically linked openssh on a squeeze box with an up-to-date openssl-dev package already installed, then simply copy the resulting binaries to the squeeze box. This will only work if static versions of the current glibc work on 2.0.x kernels. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org Please consider the environment before printing this email. E-mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Henry Schein is not liable for any loss or damage arising from this message. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
