Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Brooke, Simon
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

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

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.

Anyone?

Cheers

Simon




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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Jakob Bohm-7
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Brooke, Simon
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: [hidden email] [mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: 18 January 2012 11:37
To: [hidden email]
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                    [hidden email]
Automated List Manager                           [hidden email]



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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Michael S. Zick-4
In reply to this post by Jakob Bohm-7
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;

> > -Wall -DOPENSSL_BN_ASM_PART_WORDS \
> > -DOPENSSL_IA32_SSE2 \

And over-ride this one for the sake of the old processor.

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                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Jakob Bohm-7
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Michael S. Zick-4
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                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Michael S. Zick-4
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                    [hidden email]
> > Automated List Manager                           [hidden email]
> >
> >
>
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Brooke, Simon
In reply to this post by Michael S. Zick-4
Sadly, removing -fomit-frame-pointer does not work.

Briefly, I edited Configure, found the stanza for linux-elf, deleted -fomit-frame-pointer, and invoked

./Configure linux-elf

I then invoked

make

Once again I got the bad register name errors. I grepped to check that -fomit-frame-pointer had been removed from the Makefiles, and indeed it had.

But many thanks for the suggestion!

Cheers

Simon

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael S. Zick
Sent: 18 January 2012 14:05
To: [hidden email]
Subject: Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

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                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

wrowe
On 1/18/2012 9:57 AM, Brooke, Simon wrote:
> Sadly, removing -fomit-frame-pointer does not work.

Isn't that the default behavior for -O3?



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Michael S. Zick-4
On Wed January 18 2012, William A. Rowe Jr. wrote:
> On 1/18/2012 9:57 AM, Brooke, Simon wrote:
> > Sadly, removing -fomit-frame-pointer does not work.
>
> Isn't that the default behavior for -O3?
>

On GCC - yes.
OP is using the ancestor of what is now known as GCC.

The answer was in another person's post - his binutils
is too old to recognize the assembler instructions used.

Mike
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Brooke, Simon
I'm afraid I've now worked around the problem by using an alternative and rather less secure solution (i.e. not using openssl at all) - but it's all inside good firewalls, and the obsolete server will be phased out this year.

Issue closed, no solution found :-(

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael S. Zick
Sent: 18 January 2012 18:00
To: [hidden email]
Subject: Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

On Wed January 18 2012, William A. Rowe Jr. wrote:
> On 1/18/2012 9:57 AM, Brooke, Simon wrote:
> > Sadly, removing -fomit-frame-pointer does not work.
>
> Isn't that the default behavior for -O3?
>

On GCC - yes.
OP is using the ancestor of what is now known as GCC.

The answer was in another person's post - his binutils
is too old to recognize the assembler instructions used.

Mike
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)

Michael S. Zick-4
On Thu January 19 2012, Brooke, Simon wrote:
> I'm afraid I've now worked around the problem by using an alternative and
> rather less secure solution (i.e. not using openssl at all) - but it's all
> inside good firewalls, and the obsolete server will be phased out this year.  
>

Phasing out the obsolete server is probably the most practical approach.
 
> Issue closed, no solution found :-(
>

Just getting it to build and link may not have been the end of the problems
that would have had to be solved.

I think your old system dates from the days of libc-5, not the more recent
libc-6.  If it does, there are probably more problems lurking that just
hadn't been stumbled onto yet.  ;-)

Mike

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael S. Zick
> Sent: 18 January 2012 18:00
> To: [hidden email]
> Subject: Re: Failing to build OpenSSL 1.0.0f on obsolete Debian box (i386, kernel 2.0.36)
>
> On Wed January 18 2012, William A. Rowe Jr. wrote:
> > On 1/18/2012 9:57 AM, Brooke, Simon wrote:
> > > Sadly, removing -fomit-frame-pointer does not work.
> >
> > Isn't that the default behavior for -O3?
> >
>
> On GCC - yes.
> OP is using the ancestor of what is now known as GCC.
>
> The answer was in another person's post - his binutils
> is too old to recognize the assembler instructions used.
>
> Mike
> >
> >
> > ______________________________________________________________________
> > OpenSSL Project                                 http://www.openssl.org
> > User Support Mailing List                    [hidden email]
> > Automated List Manager                           [hidden email]
> >
> >
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
>
> 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                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]