we get correct transfer vectors for those functions when required.

guys had to change the name to differentiate with older versions when
a backward incompatibility came up.  Of course, we need to adapt.
This change simply tries to load the library through the newer name
(ZLIB1) first, and if that fails, it tries the good old ZLIB.

"remaining relocations" in assembler modules. The latter seems to
be new behaviour, elder as/ld managed to resolve this relocations
as internal. It's possible to address this problem differently,
but I settle for -Bsymbolic...
PR: 946

Notified by Corinna Vinschen <vinschen@redhat.com>

the form MBSTRING_FLAG|nbyte where "nbyte" is the number of
bytes per character.

Unfortunately this isn't so and we can't change the #defines because
this would break binary compatibility, so for 0.9.7X only translate
between the two.

for the PKCS#9 OID then the non standard MS OID.

crypto/sha/sha_locl.h, where it is in fact an int, we need to check
for less-than-zero as if it was an int...

clearerr().

last, though...

get struct timeval and gettimeofday().

Thanks to Dr Stephen Henson <shenson@drh-consultancy.co.uk> for making
me aware of this error.

around them.

NOTE: because two new locks are added, this adds potential binary
incompatibility with earlier versions in the 0.9.7 series.  However,
those locks will only ever be touched when FIPS_mode_set() is called
and after, thanks to a variable that's only changed from 0 to 1 once
(when FIPS_mode_set() is called).  So basically, as long as FIPS mode
hasn't been engaged explicitely by the calling application, the new
locks are treated as if they didn't exist at all, thus not becoming a
problem.  Applications that are built or rebuilt to use FIPS
functionality will need to be recompiled in any case, thus not being a
problem either.

the fips subdirectory, not the crypto one...