Hi,
I compiled OpenSSL 0.9.7i on a new MacIntel.
(snipp)
cc -I. -I.. -I../include -DOPENSSL_SYSNAME_MACOSX -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DOPENSSL_NO_KRB5 -DDSO_DLFCN
-DHAVE_DLFCN_H -fomit-frame-pointer -fno-common -DB_ENDIAN -c -o
mem.o mem.c
It seems
Mike Frysinger [EMAIL PROTECTED] wrote:
On Tuesday 14 February 2006 11:26, Gisle Vanem wrote:
Some of the new ts/ files are too long for a 8+3 filesystem.
a ton of files are too long for 8+3 filesystem in the openssl tarball
None of the *.[ch] files. They are all 8+3 unique AFAICS (and
via RT a écrit :
Hi,
I compiled OpenSSL 0.9.7i on a new MacIntel.
(snipp)
cc -I. -I.. -I../include -DOPENSSL_SYSNAME_MACOSX -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DOPENSSL_NO_KRB5 -DDSO_DLFCN
-DHAVE_DLFCN_H -fomit-frame-pointer -fno-common -DB_ENDIAN
[EMAIL PROTECTED] - Tue Feb 14 21:49:37 2006]:
Hi
I am getting this error when I try to compile the opensll 8a on windows XP
64 Bit Os using MS Visual Studio 2005.
.\crypto\des\enc_read.c(150) : warning C4996: 'read' was declared
deprecated
This is fixed in 0.9.8 snapshots.
Steve.
On Wednesday 15 February 2006 06:04, Gisle Vanem wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Tuesday 14 February 2006 11:26, Gisle Vanem wrote:
Some of the new ts/ files are too long for a 8+3 filesystem.
a ton of files are too long for 8+3 filesystem in the openssl tarball
None
Gisle Vanem wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Tuesday 14 February 2006 11:26, Gisle Vanem wrote:
Some of the new ts/ files are too long for a 8+3 filesystem.
a ton of files are too long for 8+3 filesystem in the openssl tarball
None of the *.[ch] files. They are all 8+3
fixed,
thanks,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL
Kurt Roeckx wrote:
Hi,
The attached patch makes some function that are only used in that
file static. There doesn't seem to be a reason to export those
functions.
patch applied to the head.
Thanks,
Nils
__
OpenSSL Project
Kyle Hamilton wrote:
...
agree, the current code is not really consistent here. If we assume
that EC_GROUP::meth cannot be NULL in a valid EC_GROUP object the
check for group-meth != NULL is superfluous and misleading and
should be removed. Done.
The check for group-meth != NULL should be