> > > > > Config was adding "386" to the Configure line causing the build
> > > > > to fail on the assembler modules.
> > > > ^^^^ in what way?
>
> UX:as: ERROR: asm/sx86-elf.s:35:invalid register for instruction: %al in xchg
Would it work if you add b to xchg mnemonic, i.e. make it look "xchgb
%al,%ah"? I'm not saying that we'll stick to 386 code, I just wonder if
xchgb does the trick.
> Have the 5 section look something like
> ----------
> 5)
> if [ "`echo x$VERSION | sed -e 's/\..*//'`" = "x7" ]; then
> echo "i586-sco-unixware7"; exit 0
> elif [ "`echo x$VERSION | sed -e 's/\..*//'`" = "x8" ]; then
> echo "i586-unknown-OpenUNIX${VERSION}"; exit 0
> fi
> ;;
> ----------
>
> An argument in favor of knowing which processor it really has would
> be if at some future date we wanted to automaticly use
> say, crypto/des/asm/des686.pl instead of
> crypto/des/asm/des-586.pl on i686.
To start with des686.pl is completely out-of-date and is not even
operational, isn't it? Then it's perfectly possible to produce blended
optimized code, and if it will be proven that des686.pl provides
*superior* preformance, I'd rather fix des-586.pl and provide *next* to
superior performance on P6 core.
To summarize. I'm hardcoding i586 to all Caldera/SCO targets. And
according to RT#460 we also should get rid of -lresolv on those
platforms, right? A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
