This is fixed, but there are similar problems that still exist, for example:
—
#include
#include
int
main(int argc, char **argv) {
return 0;
}
—
clang -Wcast-qual -o foo.o foo.c -I openssl-SNAP-20160516/include/
In file included from foo.c:1:
In file included from openssl-SNAP-20160516/inc
Attempting to compile this program:
#include
int
main(int argc, char **argv) {
return 0;
}
with -Wcast-qual (with both gcc and clang) results in errors like this
(repeated a number of times).
target/include/openssl/safestack.h:214:1: warning: cast from 'const struct
stack_st_OPENSSL
On Apr 23, 2012, at 7:53 AM, Andy Polyakov via RT wrote:
>> I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed
>> with:
>>
>> Undefined symbols for architecture x86_64:
>> "_rc4_md5_enc", referenced from:
>> _rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o)
>> ld:
I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed with:
Undefined symbols for architecture x86_64:
"_rc4_md5_enc", referenced from:
_rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o)
ld: symbol(s) not found for architecture x86_64
Looking through the CVS logs, I
I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed with:
Undefined symbols for architecture x86_64:
"_rc4_md5_enc", referenced from:
_rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o)
ld: symbol(s) not found for architecture x86_64
Looking through the CVS logs,
Here's a small patch to remove a few 'comparison between signed and
unsigned' in crypto/bn/bn_lib.c, obtained by compiling openssl 0.9.4 with
gcc -W -Wall.
Brian
--
--- bn_lib.c.oldFri Aug 20 15:59:12 1999
+++ bn_lib.cFri Aug 20 15:57:03 1999
@@ -84,28 +84,28 @@
This patch specifies a new option, NO_DSA_ASN1, which can be used to
enable DSA support without ASN1. This means that DSA_do_sign and
DSA_do_verify can be used to perform DSA computations without ASN1
functions compiled into the library.
This basically does the following things:
- moves a few f
On Thu, 1 Jul 1999, Holger Reif wrote:
> This issue seems to be the same as with Apache and SSL support. The
> conclusion was to leave out all crypto related stuff and require some
> patching. This way is sometimes not completely easy for the average
> user that wants to include other modules a
On Wed, 30 Jun 1999, Ulf [iso-8859-1] Möller wrote:
> > - US Export control issues. We only need DSA, SHA1, MD5, and randomness
> > (and possibly RSA when the patent expires). Since BIND must be
> > exportable, it would be nice to be able to strip out the code for unneeded
> > algorithms
Hi. I'm on the BIND 9 development team, and we're hoping to use OpenSSL
to perform the cryptography necessary for DNSSEC. The OpenSSL code is
portable and fast, which is exactly what we're looking for. There are a
few problems, though, and I'm not sure how much work is required to get
around th
10 matches
Mail list logo