On Wed January 18 2012, Jakob Bohm wrote:
> 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?
The: -fomit-frame-pointer
Memory tells me that is a series 3 feature not in 2.7/2.9, which
is probably silently ignoring it.
> >
> >>> -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?
No, I am not sure - it may be much newer after a bit (no pun intended)
of looking at the cpu feature bits.
The numerics: 16 17 19 21 22 mmx 24 25 26 27 28 29 31 are:
pat - Page Attribute Table
pse36 - 36-bit PSEs
no pn - processor serial number
clfls - "clflush" instruction
ds - Debug Store
acpi - ACPI via MSR
mmx
fxsr - FXSAVE/FXRSTOR
sse
sse2
ss - CPU self snoop
ht - Hyper-Threading
acc - "tm" Automatic clock control
pbe - Pending Break Enabled
And since the BogoMips computation changed (awhile back) -
it is probably a /3 for the clock estimate (1.2Ghz with Hyper-Threading).
Somebody plugged in newer hardware while you where not looking. ;-)
It is a P-IV or newer cpu.
Yup - you have sse2 - must be the older assembler.
So the suggestion to just clone this old system into another
workspace (physical machine, virtual machine) and replace __only__ the
old toolchain there for the building process may be the quick
and easy way to get this done.
Mike
> >
> > 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
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
