On 1/18/2012 1:54 PM, Michael S. Zick wrote:
On Wed January 18 2012, Jakob Bohm wrote:
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.
Looks like a Pentium-II on a very old kernel,
but I may be wrong.
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 \
If you can over-ride this one for the sake of the old toolchain;
Which one exactly?
-Wall -DOPENSSL_BN_ASM_PART_WORDS \
-DOPENSSL_IA32_SSE2 \
And over-ride this one for the sake of the old processor.
Are you sure the processor is that old and not just the assembler?
It might 'just work'
;-)
Mike
-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
