On Aug 24 23:47, Andy Polyakov wrote:
Hi,
would somebody with checkin permissions be so kind to check in the
following Cygwin-specific patch?
The patch was really overdue. It changes the layout of the Cygwin
OpenSSL distribution packages so that the runtime is separated out
into
Hi,
Why does Solaris 10 on SparcIII not suffer from this problem, is unclear to me.
We always use -lmalloc for our application, and have only one solaris 10 build
(used on all Solaris systems, regardless the processor type).
Unfortunatelly, (our) support for Solaris is system limited, and
Hi,
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Saturday, 21 August, 2010 14:42
To: Kees Dekker
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2321] bug report: core dump on
OPENSSL_cpuid_setup() on Solaris 10 with a Sun Enterprise 450
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Monday, 23 August, 2010 17:23
To: Kees Dekker
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2321] bug report: core dump on
OPENSSL_cpuid_setup() on Solaris 10 with a Sun Enterprise 450 system
Addition: building the openssl application with -lmalloc results in the same
coredump
May be dlopen(libdevinfo.so.1) and using -lmalloc does not work together (at
least on UltraSparcII).
Kees
-Original Message-
From: Kees Dekker
Sent: Tuesday, 24 August, 2010 14:25
To:
Hi,
Why does Solaris 10 on SparcIII not suffer from this problem, is unclear to me.
We always use -lmalloc for our application, and have only one solaris 10 build
(used on all Solaris systems, regardless the processor type).
Unfortunatelly, (our) support for Solaris is system limited, and we
hi, this has been shortly discussed on the OpenSSL dev list
(sent on Aug 10, 2010). I understand that given the conditions needed to
reproduce this error it will not be a priority but we believe it is a
bug worth fixing so we would like to document it in the OpenSSL RT.
Thank you.
Why does Solaris 10 on SparcIII not suffer from this problem, is
unclear to me.
Because there is a shortcut. VIS2-capable CPUs are excused from
libdevinfo voodoo and USIII is VIS2-capable CPU. Because all so-far
observed VIS2-capable CPUs has identical qualities from OpenSSL
viewpoint. VIS2