Richard Levitte [Fri, 13 Oct 2000 16:04:20 +0000 (16:04 +0000)]
Even when you don't want to create shared libraries, it's a good idea
to have the full extension information, so residual shared libraries
can be removed so the applications and test programs do not get linked
against them by mistake...
Richard Levitte [Fri, 13 Oct 2000 15:25:06 +0000 (15:25 +0000)]
Rework the system to generate shared libraries:
- Make note of the expected extension for the shared libraries and
if there is a need for symbolic links from for example libcrypto.so.0
to libcrypto.so.0.9.7. There is extended info in Configure for
that.
- Make as few rebuilds of the shared libraries as possible.
- Still avoid linking the OpenSSL programs with the shared libraries.
- When installing, install the shared libraries separately from the
static ones.
Richard Levitte [Fri, 13 Oct 2000 08:30:06 +0000 (08:30 +0000)]
Make the new conf implementatoin bug-compatible with the old one.
Actually, it's a feature that it goes looking at environment
variables. It's just a pity that it's at the cost of the error
checking... I'll see if I can come up with a better interface for
this.
Richard Levitte [Fri, 29 Sep 2000 20:14:57 +0000 (20:14 +0000)]
Include arpa/inet.h, since that's where htons() and friends are
supposed to be defined according to XPG4.2.
Found by Evan <n2xjk@ulster.net> for the MVS platform.
Bodo Möller [Tue, 26 Sep 2000 11:30:59 +0000 (11:30 +0000)]
Don't modify s->read_ahead in SSL_clear, which is called from
accept/connect functions; those should not change the
read_ahead setting of the SSL structure.
Richard Levitte [Mon, 25 Sep 2000 08:53:15 +0000 (08:53 +0000)]
'ranlib' doesn't always run on some systems. That's actually
acceptable, since all that happens if it fails is a library with
an index, which makes linking slower, but still working correctly.
print the perlasm rule only for linux-elf (it seems it confuses some
version of make for Mingw32)
----------------------------------------------------------------------
----------------------------------------------------------------------
Richard Levitte [Thu, 21 Sep 2000 15:16:20 +0000 (15:16 +0000)]
Ugly hack to make sure static libraries are usable. Without this,
anything that just links with libeay32.lib or libssl32.lib will get an
error saying the __imp__RegQueryValueEx is unresolved.
The right thing would really be to fix crypto/rand/rand_win.c to load
ADVAPI32.DLL dynamically, but that won't be done just before a
release.
Richard Levitte [Wed, 20 Sep 2000 13:55:50 +0000 (13:55 +0000)]
On VMS, stdout may very well lead to a file that is written to in a
record-oriented fashion. That means that every write() will write a
separate record, which will be read separately by the programs trying
to read from it. This can be very confusing.
The solution is to put a BIO filter in the way that will buffer text
until a linefeed is reached, and then write everything a line at a
time, so every record written will be an actual line, not chunks of
lines and not (usually doesn't happen, but I've seen it once) several
lines in one record. Voila, BIO_f_linebuffer() is born.
Since we're so close to release time, I'm making this VMS-only for
now, just to make sure no code is needlessly broken by this. After
the release, this BIO method will be enabled on all other platforms as
well.
Bodo Möller [Tue, 19 Sep 2000 23:25:00 +0000 (23:25 +0000)]
Totally remove the supposedly 'faster' variant in
BN_mod_mul_montgomery, which calls bn_sqr_recursive
without much preparation.
bn_sqr_recursive requires the length of its argument to be
a power of 2, which is not always the case here.
There's no reason for not using BN_sqr -- if a simpler
approach to squaring made sense, then why not change
BN_sqr? (Using BN_sqr should also speed up DH where g is chosen
such that it becomes small [e.g., 2] when converted
to Montgomery representation.)