On Wed January 18 2012, Michael S. Zick wrote:
> 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.
>
Which still may be a wrong guess - since your /proc/cpuinfo entry
is only decoding the first of what is now a 10 word array.
;-)
Mike
>
> 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
