On 05/04/2017 05:47 PM, Jacob Champion wrote:
> On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
>> Just as a heads up as I currently don't have time to investigate further. I
>> get the below on CentOS 6.9 64 bit, which
>> puzzles me a little bit as I would expect the errno addresses to be
>> dif
On 05/04/2017 09:39 AM, Jacob Champion wrote:
On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
Ugh... This suggests we've further broken crosscompile, just noticed
this based on your comment.
Why? Cross-compilation uses the same fallback mechanism.
To expand on this, there are three choices
On 05/04/2017 09:36 AM, William A Rowe Jr wrote:
Ugh... This suggests we've further broken crosscompile, just noticed
this based on your comment.
Why? Cross-compilation uses the same fallback mechanism. If a user
doesn't like the conservative choice, he/she should set the cachevars to
overrid
On May 4, 2017 10:47 AM, "Jacob Champion" wrote:
On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
> Just as a heads up as I currently don't have time to investigate further.
> I get the below on CentOS 6.9 64 bit, which
> puzzles me a little bit as I would expect the errno addresses to be
> differe
On 05/03/2017 11:25 PM, Ruediger Pluem wrote:
Just as a heads up as I currently don't have time to investigate further. I get
the below on CentOS 6.9 64 bit, which
puzzles me a little bit as I would expect the errno addresses to be different
in different threads on my OS.
[Thu May 04 06:17:13.
On 04/19/2017 05:54 PM, Jacob Champion wrote:
> On 04/12/2017 11:34 AM, Jacob Champion wrote:
>> It's probably worth noting at this point that, even if &errno is unsafe:
>>
>> - Windows and BeOS users are still handled explicitly by default in 1.0.x.
>> - If OpenSSL still provides the deprecated
On 04/12/2017 11:34 AM, Jacob Champion wrote:
It's probably worth noting at this point that, even if &errno is unsafe:
- Windows and BeOS users are still handled explicitly by default in 1.0.x.
- If OpenSSL still provides the deprecated CRYPTO_set_id_callback(), we
can use it instead. We're not
>I saw it in the header file, but actually testing it on Solaris 10 Sparc
>showed that the address was different as well in different threads. Can
>you try on you system as well?
Actually, my system is OpenIndiana, but you're right.
The address of ___errno() function is same,
but the return value
Am 13.04.2017 um 23:40 schrieb Tsuyoshi SASAMOTO:
...oh. So errno is actually threadsafe, but its "address" is the same in
every thread? Interesting.
MT-Safe errno of Solaris is implemented as a function,
so its address is same but the value is different.
cf. https://src.illumos.org/source/xref
>...oh. So errno is actually threadsafe, but its "address" is the same in
>every thread? Interesting.
MT-Safe errno of Solaris is implemented as a function,
so its address is same but the value is different.
cf. https://src.illumos.org/source/xref/illumos-gate/usr/src/head/errno.h
https://src
On 04/12/2017 07:53 AM, Rainer Jung wrote:
The good news:
I checked by compiling your test program standalone (outside of
configure) to be able to run it easily very often (1000 times). I
checked on Solaris 8 (32 Bit) and 10 Sparc (32 Bit and 64 Bit) compilation.
When I compile without any flag
Hi Jacob,
Am 12.04.2017 um 02:16 schrieb Jacob Champion:
On 04/10/2017 03:59 PM, Jacob Champion wrote:
So it looks like my test program might still be a possible solution for
detecting whether we need a callback at configure time, unless anyone
knows of a platform where two thread-local errnos
On 04/10/2017 03:59 PM, Jacob Champion wrote:
So it looks like my test program might still be a possible solution for
detecting whether we need a callback at configure time, unless anyone
knows of a platform where two thread-local errnos can have the same
address some of the time and different ad
On 04/10/2017 03:21 PM, Rainer Jung wrote:
Am 10.04.2017 um 22:41 schrieb Jacob Champion:
A few questions for the list while I'm brainstorming the best way to fix
https://bz.apache.org/bugzilla/show_bug.cgi?id=60947 ...
- What is the oldest version of OpenSSL we'll support for the 2.4.x
line? W
Am 10.04.2017 um 22:41 schrieb Jacob Champion:
A few questions for the list while I'm brainstorming the best way to fix
https://bz.apache.org/bugzilla/show_bug.cgi?id=60947 ...
- What is the oldest version of OpenSSL we'll support for the 2.4.x
line? Will that version change in 2.next?
For 2.4
15 matches
Mail list logo