On 5/22/2013 8:20 AM, Amos Jeffries wrote:
Things to be aware of:
* feature-detection by ./configure can fail when there are more than one
library version installed. The feature detecion may test the OS default
library in /usr, then some unrelated library adds /usr/local or /opt or
similar where files for a second library version gets used by the build.
This is true for all libraries, not just OpenSSL.
The fix here is to explicitly point --with-openssl= at the particular
path for the desired library whenever there are more than one installed.
* These feature-detection patches make allowance for most permutations
of the known problems. But cannot handle the event where both our
workaround and the official API are failing. If you can be certain you
are hitting one of these cases we would like to know what OpenSSL
version is doing it
* the FIPS library versions which were also failing earlier with
apparently the same build errors. I believe these FIPS builds are also
fixed as a result of the featrue detection, but that is so far
unconfirmed. I do know the FIPS libraries have significantly more chance
of hitting the above case where our workarounds do not work.
* There may be other OpenSSL API problems hidden in any given library
which we are still unaware of and unfixed. 3.3.5 changes only decouple
the existing version-based workarounds from the library version.
In any event, the only real fix for these problems is to replace the
broken library versions with update working ones.
Can it be that two exactly identical CentOS systems do the same
configure and make will result in a different result?
They only thing I can think of is a corrupted library that result in a
corrupted library on the OS and this is not a very nice thing to know.
To make sure our libs are identical we can use SHA1 or a more complex
calculation to verify his lib corruption reason.
Eliezer
Amos
