Re: [openssl.org #451] SX6 port
I already answered this once, but it didn't come through for some reason... + sx6, cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::, No optimization? Not even lousy -O? -g overrides any optimization you give, Yes, that's what normally happens... and i think there's a problem with the optimizer anyway because with default optimization, aes-128-cbc test fails. it's fine with -g. I wonder if AES is the only one affected. Could you run 'make -k test' and submit output? A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
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]
Re: [openssl.org #463] PATCH
1)I didn't give any preference to aix-cc;
But you've suggested to change it:-)
I just changed
in config script the default CC=gcc to CC=cc for AIX case only.
Is vendor compiler optional on AIX? Because if it is, then you've got to
test if cc is actually present. Normally it's done by passing a tell me
what version you are flag to cc and examining the output. As I can't
find such flag in AIX cc manual page so that we probably have to go for
'(cc) 21 | grep -iv command not found /dev/null CC=cc'...
3)My understanding is that our AIX machine should support 64 bits,
at least static libraries libssl.a libcrypto.a were built
but aix-shared target failed. So, it there is a correct line
in the Makefile for aix64-cc, I hope it will build shared libraries.
4)I have copied my original message to [EMAIL PROTECTED]
and was assigned a bug number; I don't know if it was necessary.
Thank you very much for your attention,
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 4:27 PM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
Current version,
openssl-0.9.7, does not support shared libraries on AIX platform.
To openssl-dev mainly. How come did do_aix-shared deserve so special
treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
Just wondering...
I am sending you the changes
which allow to generate shared libraries for some cc compilers on AIX, namely,
aix-cc
What's the idea behind aix-cc? It's a safety net for out-of-date AIX
releases, which noone cared to test for a long time and probably never
will. If you just tested both aix-cc and aix43-cc on the same machine,
then we should refrain from modifying the aix-cc. Alternative is to
rename aix-cc to aix-old-cc and aix43-cc to aix-cc and leave aix-old-cc
alone...
and aix43-cc.
Could you test following? In a tree with proposed patch applied! Open
Makefile.ssl with text editor, seek to do_aix-shared rule, modify
SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE above the rule
as SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE. Finaly 'make
clean' and 'make'. Does it build? I want to see if it's possible to get
rid of that extra step which generates .exp file...
These changes are not made for aix64-cc,
But do you have acces to an AIX workstation which supports 64-bit ABI? I
mean in case an alternative line is proposed will you be able to test
it? Do you know if AIX cc supports inline assembler?
A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
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
;;
--
Updated config is in both HEAD and 0.9.7-stable CVS. Please verify and
reply so that the ticket can be resolved. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
On Sat, 18 Jan 2003, Andy Polyakov via RT wrote: 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. Yes it does. 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. OK. 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. Carfefull when you start talking about all Caldera/SCO targets SCO has Linux based products and two totally different UNIX based products. Don't interchange OpenServer and UnixWare. (OpenUNIX is UnixWare 7.1.2) But yes, hardcoding the UnixWare/OpenUNIX targets to i586 would be fine. And yes, get rid of -lresolv on the sco5 (OpenServer 5) targets. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
On Sat, 18 Jan 2003, Andy Polyakov via RT wrote: 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. Yes it does. 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. OK. 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. Carfefull when you start talking about all Caldera/SCO targets SCO has Linux based products and two totally different UNIX based products. Don't interchange OpenServer and UnixWare. (OpenUNIX is UnixWare 7.1.2) But yes, hardcoding the UnixWare/OpenUNIX targets to i586 would be fine. And yes, get rid of -lresolv on the sco5 (OpenServer 5) targets. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
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. And yes, get rid of -lresolv on the sco5 (OpenServer 5) targets. The question also is if it's needed even in unixware-2.* lines. As already mentioned openssl does not use functions normally found in libresolv. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a signed and then encrypted pkcs7 message on windows 98 using Crypto API
On Fri, Jan 17, 2003, Himanshu Soni wrote: 128 Bit rc2 also fails on windows 98. Openssl can successfully decrypt the message on windows 98. Hmmm, strange. Have you tried an alternative certificate for the Win98 recipient? Also what does a signed message look like for that certificate, in particular what SMIMECapabilities do you get, if you aren't sure about that email me a signed message created using that certificate. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #464] TSU NOTIFICATION - encryption
On Sat, 18 Jan 2003, Andy Polyakov via RT wrote:
Have the 5 section look something like
--
[snip]
Updated config is in both HEAD and 0.9.7-stable CVS. Please verify and
reply so that the ticket can be resolved. A.
UX:sh (./config): ERROR: ./config: Syntax error at line 442: `fi' unexpected
x8*) echo i586-unkn-OpenUNIX${VERSION}; exit 0 ;;
^
Missed a closing quote |
Other than that UnixWare 7 and OpenUNIX 8 work fine.
I think we should hard code the UnixWare 2.x section (4.2MP)
Pentiums were the current processor at the time 2.01 was released.
If anyone is actually running 2.x on a i386 they can pass the 386 option
on the command line.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #444] Win32 crash in PEM_read_X509
Did you build a debug version of OpenSSL to link against for the debug build? This isn't handled automatically and you need to change it so it picks up and uses the debug libraries. Nope. that would explain it. criss-crossing MS multi-threaded libs is always a problem. I was using my debug build (the release was probably set up somewhat incorrectly since I had not touched it yet), so I was using a mismatched pair of libs. thanks for the clarification. michael __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
