[openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC
dclarke at blastwave.org
Sat Feb 24 20:21:32 UTC 2018
On 24/02/18 02:18 PM, Erik Forsberg wrote:
>> -- Original Message --
>>>>>> As for -lm, which symbol was undefined?
>>>>> Undefined first referenced
>>>>> symbol in file
>>>>> fabs test/ct_test.o
>>>> ??? One can only wonder where does it come from. I see no fabs
>> Ah! Missed it! There is fabs call in ct_test. I was looking for
>> reference in binary code. On multiple platforms including Solaris x86.
>> Question is how come it isn't a problem anywhere else. It looks like
>> it's customarily inlined, but not here. Well, you insist on
>> -xbuiltin=%none, so I suppose this has to be it. In such case it's on you...
> Most compilers (including gcc) inlines fabs()
> Solaris cc does not when using -O0 -g which I use when debugging.
> If I remember correctly, solaris cc also inlines when using higher level of optimization
> but I may remember wrong.
I like having nice debug builds first that I can single step through if
needed. The joy of fast processors and buckets of cheap memory is that
I can have an entire dev type amp stack that runs just fine with debug
libs everywhere and then a prod stack which is slightly more optimal.
In any case, this seems to me like we are fetching a unit64_t type of
number for milliseconds and should just check if it is within 600000
of some value for "now". No need for the divide by 1000 in there.
Looking in ./include/openssl/ct.h we see :
* Gets the time, in milliseconds since the Unix epoch, that will be
used as the
* current time when checking whether an SCT was issued in the future.
* Such SCTs will fail validation, as required by RFC6962.
uint64_t CT_POLICY_EVAL_CTX_get_time(const CT_POLICY_EVAL_CTX *ctx);
OKay so it is an uint64_t for milliseconds. Perfect. So maybe just use
that in line 503 :
uint64_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx);
What in the name of Smokey Robinson is TEST_uint_le? Looks to be a
"define" in ./test/testutil.h :
# define TEST_uint_le(a, b) test_uint_le(__FILE__, __LINE__, #a, #b, a, b)
uh huh ... and in turn where is test_uint_le coming from ?
I don't know. No where in the tarball that is for sure.
I do see it out in the world at :
Seems like a test for "less than or equal to" for two uintXX_t things.
Regardless there isn't a need for a double difftime nor a floating point
fabs here. Am I missing something obvious ?
More information about the openssl-users