[[EMAIL PROTECTED] - Sun Jan 19 08:28:56 2003]:
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
Yes, that is a common one, though it was more prevalent in early MSVC7
(.NET) than in MSVC6. Another common problem is nested for loops.
If you just can't figure out why a particular function is generating bad
asm code, it is also possible to use #pragma optimize(off,0) (syntax
might be
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
Oh. That could account for the problem if OpenSSL is using the release
build of the multi-threaded DLL's and my build of tunala is using the debug
ones. I assume that was on the release build that you changed it,
right? If on the debug build it should be correct to use the debug
[[EMAIL PROTECTED] - Fri Jan 17 18:58:35 2003]:
Oh. That could account for the problem if OpenSSL is using the
release
build of the multi-threaded DLL's and my build of tunala is using the
debug
ones. I assume that was on the release build that you changed it,
right? If on the debug
At 06:02 PM 1/15/2003 +0100, you wrote:
If you just can't figure out
Just to clarify. The posted patch is not so to say try-your-luck
thing, it *does* get me through the ms\test.
Understood, but it was unclear if it fixed the bug I posted in the PEM
read, which is very likely a similar
what did you do to get tunala to compile under Win32?
Oh, that. I have been meaning to send Geoff the diff so it could get
merged into the code base. I'll get to it some day. I had to wrap up
sockets a little and make a few mods in ip. Here is a zip of it with the
DSP. Some project
[[EMAIL PROTECTED] - Thu Jan 16 18:39:44 2003]:
what did you do to get tunala to compile under Win32?
Oh, that. I have been meaning to send Geoff the diff so it could get
merged into the code base. I'll get to it some day. I had to wrap up
sockets a little and make a few mods in
[[EMAIL PROTECTED] - Wed Jan 15 07:08:15 2003]:
That would certainly seem like a good first step.
Have you traced into it at all? I.e. have you run with debug setup
and
seen a stack trace s.t. you know the function that is crashing and
what
variable is bad (a null pointer or something)?
One is that AES using 192 or 256 bit ciphers produces the wrong result.
Have you traced into it at all?
Try this:-)
--- ./crypto/aes/aes_core.c.origWed Nov 13 15:01:18 2002
+++ ./crypto/aes/aes_core.c Wed Jan 15 01:54:08 2003
@@ -750,7 +750,7 @@
rk[2] = GETU32(userKey +
Yes, that is a common one, though it was more prevalent in early MSVC7
(.NET) than in MSVC6. Another common problem is nested for loops.
If you just can't figure out why a particular function is generating bad
asm code, it is also possible to use #pragma optimize(off,0) (syntax
might be
If you just can't figure out
Just to clarify. The posted patch is not so to say try-your-luck
thing, it *does* get me through the ms\test.
But then you have to remember to go
fix it some day and remove the #pragma.
??? Fix what? It's the compiler that needs to be fixed... A.
[[EMAIL PROTECTED] - Wed Jan 15 18:02:51 2003]:
If you just can't figure out
Just to clarify. The posted patch is not so to say try-your-luck
thing, it *does* get me through the ms\test.
aol
me too
/aol
The PEM crash mentioned by the OP though I'm not sure how to reproduce:
It is
That would certainly seem like a good first step.
Have you traced into it at all? I.e. have you run with debug setup and
seen a stack trace s.t. you know the function that is crashing and what
variable is bad (a null pointer or something)? IF so, I may be able to
provide the work around
[steve - Fri Jan 10 01:33:03 2003]:
I've managed to download SP5 and the processor add on pack.
With VC++ 6.0 and SP5 only it passes all tests.
With VC++ 6.0, SP5 and processor add on it misbehaves and things like
AES give invalid results.
After playing around with various options it
[[EMAIL PROTECTED] - Thu Jan 9 08:17:07 2003]:
At 02:14 AM 1/9/2003 +0100, you wrote:
[[EMAIL PROTECTED] - Wed Jan 8 22:09:03 2003]:
Assuming that isn't the case I've also just been tracing the cause of
a
problem with VC++ SP4 with the processor pack.
It was giving incorrect
I've managed to download SP5 and the processor add on pack.
With VC++ 6.0 and SP5 only it passes all tests.
With VC++ 6.0, SP5 and processor add on it misbehaves and things like
AES give invalid results.
After playing around with various options it seems that disabling global
optimization with
html
body
Version 0.9.7 release version from Dec 31, 2002br
Compiled using MSVC6 sp6 with Masmbr
OS: Windows XP Homebrbr
When PEM_read_X509 is called in certain circumstances you get an
unhandled exception. I thought it was universal, but I found a test case
in the quot;how to reproducequot;
[[EMAIL PROTECTED] - Wed Jan 8 22:09:03 2003]:
html
body
Please don't post using HTML...
Version 0.9.7 release version from Dec 31, 2002
Compiled using MSVC6 sp6 with Masm
Where is SP6 for MSVC6? I can only see SP5 on MS site...
OS: Windows XP Homebrbr
When PEM_read_X509 is called in
At 02:14 AM 1/9/2003 +0100, you wrote:
[[EMAIL PROTECTED] - Wed Jan 8 22:09:03 2003]:
html
body
Please don't post using HTML...
Sorry, I did not know that I had. Wasn't this post from the tracker on the
OpenSSL site? If not, it must be some setting I have accidentally on in
Eudora or
20 matches
Mail list logo
