Matt Caswell wrote:
> The complete patch is attached. This is currently going through review,
> and solves the link issue.
That brought MSVC-2015 back on track. Thanks!
--
--gv
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Matt Caswell wrote:
> The attached seems to avoid the problem - but then for reasons I cannot
> understand link errors result later on in the build.
I too can confirm that your patch fixes MSVC-2105 compilation.
Thanks a million!
But as you wrote, the link fails. Due to util/mkdef.pl needs
an
Viktor Dukhovni wrote:
> On Mon, Feb 22, 2016 at 03:55:12PM -1000, Bill Bierman wrote:
>
>> The Microsoft compiler team has suggested removing the include of ssl.h
>> from srtp.h as it creates a circular reference which is likely confusing
>> the compiler.
>
> Could you test the patch below.
Rich Salz wrote:
> #ifdef CIPHER_DEBUG
> fprintf(stderr,
> -"Applying rule %d with %08lx/%08lx/%08lx/%08lx/%08lx %08lx
> (%d)\n",
> +"Applying rule %d with %08x/%08x/%08x/%08x/%08x %08x (%d)\n",
> rule, alg_mkey, alg_auth, alg_enc, alg_mac, alg_ssl,
>
The ssl/t1_enc.c file doesn't compile with '-DTLS_DEBUG':
ssl/t1_enc.c: In function 'tls1_setup_key_block':
ssl/t1_enc.c:528:30: error: 'p1' undeclared (first use in this function)
printf("%02X%c", p1[z], ((z + 1) % 16) ? ' ' : '\n');
I assume that should be:
printf("%02X%c",
FYI.
Take a look at how the commit logs of OpenSSL can be visualised
using the cool program Gource [1]:
https://www.youtube.com/watch?v=068ePuZ5OWw
Notice how the Heartbleed (?) bug caused the commit rate and number
of contributors increases at time 8:10 (May 2014).
[1]
Kurt Roeckx wrote:
> So we've been seeing this on AppVeyor too. As far as I can see,
> this happens somewhere between commit 249d9719 and 59fd40d4. The
> file itself has only minor changes, turning some "SSL_CIPHER *"
> into "const SSL_CIPHER *", so it's most likely one of the include
> files
There seems to be some memory leak(s) somewhere during the life
of 's_client_main()'. Example from a client.bat here:
set OPENSSL_DEBUG_MEMORY=on
echo -e GET /ssltest/viewMyClient.html\r\n | openssl.exe s_client ^
-connect www.ssllabs.com:443
('echo -e' is from Cygwin32).
All
Having '-DCIPHER_DEBUG' in the CFLAGS causes this error in
MingW (gcc 5.1):
ssl/ssl_lib.c:2499:58: error: 'dh_dsa' undeclared (first use in this function)
dh_tmp, rsa_enc, rsa_sign, dsa_sign, dh_rsa, dh_dsa);
(+ a lot wore warnings). Time to retire/rewrite this 'CIPHER_DEBUG'
part?
Salz, Rich wrote:
c_zlib.c:113:5: warning: excess elements in struct initializer
NULL,
^~~~
Are you sure you have an accurate copy of master?
The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 as part of
making the COMP structures opaque.
He's right, the
Matt Caswell wrote:
I just posted the following to lynx-dev:
I didn't get that post.
The OP suggested this:
+#if (OPENSSL_VERSION_NUMBER = 0x1010L)
+ ssl_ctx = SSL_CTX_new(TLSv1_client_method());
+#else
ssl_ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
This is not
I'm truly amazed that this error has been in there so long.
From MingW's gcc:
crypto/threads/th-lock.c:130:13: error: static declaration of
'CRYPTO_thread_cleanup' follows non-static declaration
crypto/threads/th-lock.c:89:6: note: previous declaration of
'CRYPTO_thread_cleanup' was here
Mike Bland mbl...@acm.org wrote:
Still, it does look like the single-Makefile results are a win.
Yes, I agree. That's what I've done for years on Win32 (MSVC + MingW) with
this single GNU makefile:
http://www.watt-32.net/misc/openssl-windows.zip
Actually 2 files; Options.Windows and
Linda Zhang lind...@qq.com wrote:
2. There is a conflict of the order of winsock2.h and windows.h in some source
files so that the compiler shows error messages:
#error ws2tcpip.h is not compatible with winsock.h. Include winsock2.h
instead.
mingw32-make: *** [tmp\t1_lib.o] Error 1
Linda Zhang lind...@qq.com wrote:
So, I build openssl with command line ms\mingw32.bat. It seems there must be
something wrong that it didn't pass CFLAGS configured by perl Configure mingw
to
gcc.
OpenSSL (on Windows at least) is close to the package from hell. Someone here
remember gettext?
Ding, Jeff via RT r...@openssl.org wrote:
.\ssl\s23_clnt.c(286) : error C2220: warning treated as error - no 'object' file
generated
.\ssl\s23_clnt.c(286) : warning C4244: 'initializing' : conversion from 'time_t'
to 'unsigned long', possible loss of data
...
Adding the typecast prevents the
Here's a small patch to crypto/sha/asm/sha512-586.pl.
My assemblers (ml nasm) correctly complains on lines like:
./tmp32/sha512-586.S:515: error: mismatch in operand sizes
which is:
movq mm4,DWORD PTR 24[esp]
In fact it must be:
movq mm4,QWORD PTR 24[esp]
Hence with this small patch, it
dkauf...@rahul.net via RT r...@openssl.org wrote:
The latest tarball for head failed to compile for DJGPP because an
include file from the WATT32 distribution (tcp.h), required in the DJGPP
build, defines byte as unsigned char. This patch renames byte to
byte_ssl in ssl/ssl_rsa.c to avoid the
It's quite an achievement for a open-source project to not touch a file for
11 years :) The 'crypto\cast\cast_s.h' file is still missing a header guard.
Just a FYI:
--- openssl-SNAP-20110407\crypto\cast\cast_s.h Tue Feb 15 20:00:20 2000
+++ crypto\cast\cast_s.hWed Feb 16 18:33:28 2011
Suddenly crypto/lhash/lh_test.c no longer compiles. From todays snapshot
(on MingW):
crypto/lhash/lh_test.c:65: warning: return type defaults to `int'
crypto/lhash/lh_test.c: In function `main':
crypto/lhash/lh_test.c:66: error: `LHASH' undeclared (first use in this
function)
Where are functions like EVP_seed_ecb() and other functions
inside #ifndef OPENSSL_NO_SEED implemented?
Now I have to build using '-DOPENSSL_NO_SEED' to get things
to link.
I've built everything fresh from a tar-ball from 3 days ago:
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20080107.tar.gz
Where are functions like EVP_seed_ecb() and other functions
inside #ifndef OPENSSL_NO_SEED implemented?
Forget it; found it in crypto/evp/e_seed.c.
--gv
__
OpenSSL Project http://www.openssl.org
This file lacks a header-guard. It's needed since it is
included multiple times in crypto/des/des_opts.c (via
des_enc.c). Patch:
--- orig/crypto/des/spr.h 2002-03-04 18:01:16 +0100
+++ crypto/des/spr.h2007-03-19 18:32:56 +0100
@@ -56,6 +56,9 @@
* [including the GNU Public Licence.]
*/
Victor B. Wagner [EMAIL PROTECTED] wrote:
It'll be interesting to see if ccgost engine can work at all under DOS -
we never intended it to be used on the platform without dynamic loading,
and OpenSSL doesn't support dynamic loading, available in DJGPP 2.04.
gost_eng.c has some code inside
There is a problem building OpenSSL on a 8+3 filesystem like
DOS due to the files:
engines/ccgost/gost2001.c
engines/ccgost/gost2001_keyx.c
The latter overwrites the first using djgpp's tar. Could you please
rename them to something like:
engines/ccgost/gost01.c
engines/ccgost/gost01_keyx.c
so
As it is now one must add OPENSSL_RFC3779 to the CFLAGS
to make todays snapshot to build. Otherwise I'm getting link
errors like:
Cannot export ASIdOrRange_free: symbol not defined
Shouldn't defines like:
#ifdef OPENSSL_RFC3779
be replaced with:
#ifndef OPENSSL_NO_RFC3779
Or is it required
Bodo Moeller wrote:
Makes sense. I'll put this into the CVS (applicable to the 0.9.9-dev
branch only, if anyone is wondering -- i.e., this mismatch isn't in
any of the releases).
The change is in the CVS, but it's still not in the snapshot at:
crypto/rsa/rsa_locl.h wrongly uses 'size_t' in some arguments. It should
match the implementation in crypto/rsa/rsa_sign.c (what happened to this
file?). A patch:
--- orig/crypto/rsa/rsa_locl.h 2006-08-28 19:01:02 +0200
+++ crypto/rsa/rsa_locl.h 2006-08-29 15:30:50 +0200
@@ -1,4 +1,4
One other thing is that cmll_loc.h includes intypes.h for non-MSCV
targets. This header is not omni-present. A patch for djgpp at least:
--- crypto\camellia\cmll_loc.org2006-07-20 17:01:50 +0200
+++ crypto\camellia\cmll_loc.h 2006-07-20 16:57:54 +0200
@@ -77,6 +77,8 @@
typedef unsigned
Some patches needed to build the test-programs on MingW:
* 'struct tms' is not available on MingW. So don't define TIMES.
* main() returns an int.
* don't use deprecated BN_CTX_init(). Use BN_CTX_new() instead.
* added header-guard to crypto/des/spr.h
* include openssl/pem.h and openssl/err.h to
There should be no reason to typecast the argument to
CRYPTO_set_locking_callback():
diff -u3 -Hb -r openssl-SNAP-20060713\crypto\threads\th-lock.c
crypto\threads\th-lock.c
--- openssl-SNAP-20060713\crypto\threads\th-lock.c Fri Mar 21 18:15:34 2003
+++ crypto\threads\th-lock.c Thu Jul 13
With the following patch I'm able to link openssl.exe using the DLL
(and not the static libs):
--- orig/util/libeay.num Mon Apr 17 15:01:06 2006
+++ util/libeay.num Fri May 12 16:52:48 2006
@@ -3683,3 +3683,6 @@
EVP_PKEY_verify_recover 4079 EXIST::FUNCTION:
Do as the apps/apps.h prototypes:
--- apps\apps.c.origSun Apr 09 12:00:11 2006
+++ apps\apps.c Wed Apr 12 17:57:37 2006
@@ -2673,7 +2673,7 @@
#endif
#if defined(_WIN32) defined(STD_OUTPUT_HANDLE)
-int raw_write_stdout(void *buf,int siz)
+int raw_write_stdout(const void *buf,int siz)
Why is it that (not all?) functions in evp.h and pem.h isn't exported? That
is; there are no entries in util\libeay.num for them. Because of this,
I'm unable to bind to OpenSSL dynamically when building openssl.exe.
Just curious.
--gv
Dr. Stephen Henson [EMAIL PROTECTED] wrote:
Do you mean those in 0.9.9-dev? Occasionally when something isn't quite
stabilized libeay.num isn't updated straight away. You can update it yourself
using the info in INSTALL.W32. Note however that the numbers it assigns may
change when these become
But then this patch:
--- util\ssleay.num.origWed Apr 12 20:11:22 2006
+++ util\ssleay.num Wed Apr 12 18:25:52 2006
@@ -231,3 +231,5 @@
SSL_get_psk_identity_hint 280EXIST::FUNCTION:
SSL_get_psk_identity281EXIST::FUNCTION:
Since a few days back, crypto/objects/obj_dat.c doesn't compile.
Here are the errors from gcc:
2112: error: `NID_id_GostR3410_94_cc' undeclared here (not in a function)
2112: error: initializer element is not constant
2112: error: (near initialization for `nid_objs[797].nid')
2113: error:
As the comment in b_print.c says;
As snprintf is not available everywhere, we provide our own implementation
So we should use BIO_snprintf() in apps/s_client.c and ssl/ssltest.c.
The other patch to ssltest.c fixes the missing newline problem under DOS
and Windows. Patch attached.
--gv
---
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
Some of the new ts/ files are too long for a 8+3 filesystem.
ts_req_print.c
ts_req_utils.c
ts_resp_print.c
ts_resp_sign.c
ts_resp_utils.c
ts_resp_verify.c
ts_verify_ctx.c
I only ask if the ts_resp_*.c files could be renamed to
ts_rsp_*.c.
--gv
Using the snapshot from today, linking fails due to missing
'openssl_fcast':
crypto/asn1/p5_pbe.c: In function 'PKCS5_pbe_set':
crypto/asn1/p5_pbe.c:109: warning: implicit declaration of function
'openssl_fcast'
crypto/asn1/p5_pbev2.c: In function 'PKCS5_pbe2_set':
crypto/asn1/p5_pbev2.c:167:
My previous message seems to have got lost somewhere; it is
not in the archive.
- Original Message -
From: Gisle Vanem [EMAIL PROTECTED]
To: OpenSSL-dev openssl-dev@openssl.org
Sent: Tuesday, January 18, 2005 2:23 PM
Subject: [Patch] ssltest.c
Currently ssltest.exe prints to stdout
Currently ssltest.exe prints to stdout/stderr using binary mode on
DOS/Win32. So the screen output is all screwed:
ssltest.exe -d -v -time -server_auth
Using BIO pair (-bio_pair)
Warning: For accurate timings, use more connections (e
.g. -num 1000)
Available
AES_set_encrypt_key() etc. are multiple defined (in aes-586.pl
and aes_core.c). Patch:
--- aes_core.c.orig 2004-12-23 21:00:10.0 +0100
+++ aes_core.c 2005-01-15 11:13:02.0 +0100
@@ -736,6 +736,7 @@
0x1B00, 0x3600, /* for 128-bit blocks, Rijndael never uses more than
10
Doug Kaufman wrote:
The code for watt-32 debugging didn't appear to be implemented
correctly. This should only be called when desired; otherwise large
files will be created, documenting every byte going through tcp. In
addition dbug_init() should be called only once, but was being called
multiple
All the snapshot files for today are all zero bytes. E.g.
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20041122.tar.gz
What's causing this?
--gv
__
OpenSSL Project http://www.openssl.org
Development
This file has a 'explicit' struct x509_store_ctx_st member. This words is
unfortunetely a C++ reserved word in g++ 3.4.1 at least. And from a bit of
googling, has been a reserved word for more than 6 years.
I suggest we replace with 'explicit_policy'.
--- crypto/x509v3/x509_vfy.h.orig Sat
I tried compiling for MingW and with OPENSSL_EXPORT_VAR_AS_FUNCTION
defined. But struck a gcc 3.4.1 error because of extern static
Patch:
--- orig/e_os2.h Tue Jul 27 16:00:12 2004
+++ e_os2.h Sun Sep 26 15:07:24 2004
@@ -268,7 +268,7 @@
*/
#ifdef OPENSSL_EXPORT_VAR_AS_FUNCTION
I tried building all the sample programs by linking to the
DLL import libs. All okay except for sha512t.exe:
sha512t.o(.text+0x42):sha512t.c: undefined reference to `OPENSSL_ia32cap_loc'
AFAICS because OPENSSL_ia32cap_loc() isn't in the libeay32.def file.
It's neither in the util/libeay32.num
Andy Polyakov wrote:
Latest relevant update is more picky and requires yet another assembler
module compiled and linked in.
You mean x86cpuid.o? Got that.
I'd rather discuss proper and complete support for assembler modules in
DJGPP than trying to figure out what went wrong with your
Allthough djgpp isn't Unix, it does have opendir() and friends:
--- ./orig/crypto/o_dir.cSat Jul 10 15:15:58 2004
+++ ./crypto/o_dir.cSun Jul 18 20:15:46 2004
@@ -70,7 +70,7 @@
#include o_dir.h
#define LPDIR_H
-#if defined OPENSSL_SYS_UNIX
+#if defined OPENSSL_SYS_UNIX || defined DJGPP
From snapshot in May with SSE2 enabled:
type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
sha-512 3171.75k12757.93k22761.88k34514.56k40059.42k
But now it's back to non-SSE2 speed:
type 16 bytes 64 bytes256 bytes
Lev Walkin [EMAIL PROTECTED] said:
No, fnmatch() is fairly portable across Unixes though.
Please note that fnmatch() use is against RFC2818.
Please explain why.
--gv
__
OpenSSL Project
Andy Polyakov [EMAIL PROTECTED] said:
As far as I can see stock OpenSSL doesn't generate assembler moduler
for DJGPP, so you've got to tell more details about how do you generate
assembler modules. Note that picmeup is used in des assembler modules.
Can you figure out how it works there?
Andy Polyakov [EMAIL PROTECTED] said:
400% on large blocks.
4x? What gcc version? 3x mentioned in commentary section is also for
largest block and with gcc 2.95.3. Well, not that 4x is worse result...
I used gcc 3.3.1 with -O2 -fno-strength-reduce -fomit-frame-pointer.
As for
I got that part. But AFAICS, when strtol(env,NULL,0) is used to set
OPENSSL_ia32cap and env = 0x0400, strtol() treats the value
as octal. From mn strtol:
The string may begin with an arbitrary amount of white space (as
determined by isspace(3)) followed by a single optional + or -
With SSE2 disabled:
openssl speed sha-512:
...
type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
sha-512 1050.62k 4223.53k 6141.97k 8488.01k 9480.48k
with SSE2 enabled:
type 16 bytes 64 bytes256 bytes 1024 bytes 8192
Gisle Vanem via RT [EMAIL PROTECTED] said:
4008:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:crypto/asn1/tasn_dec.c:395:Type=X509
4008:error:1409000D:SSL routines:SSL3_GET_SERVER_CERTIFICATE:ASN1
lib:ssl/s3_clnt.c:842:
I thik this patch fixes it:
G:\MingW32\src
Using the 24 April snapshort compiled on Windows (MingW)
and running:
echo GET /ucgi/browsercheck.exe | openssl.exe s_client -connect www.thawte.com:443
produces these errors:
Loading 'screen' into random state - done
4008:error:2507006C:DSO support routines:DSO_load:functionality not
Is there any reason why this error isn't among the non-fatal
errors in BIO_sock_non_fatal_error() (in crypto/bio/bss_file.c) ?
MSDN has this to say:
WSAINPROGRESS:
A blocking Windows Sockets 1.1 call is in progress, or the service
provider is still processing a callback function.
...
A
Just a little detail, so it doesn't create Watt-32 debug-files
unconditionally:
--- apps\s_socket.c.orig Sat Dec 27 16:00:40 2003
+++ apps\s_socket.c Sat Mar 27 12:56:50 2004
@@ -171,8 +171,11 @@
{
#ifdef WATT32
extern int _watt_do_exit;
- _watt_do_exit = 0;
+
The d2i_X509_CINF() is prototyped through some hairy
ifdef's by DECLARE_ASN1_FUNCTIONS(X509_CINF)
The implementation in x_cinfo.c is however missing a 'const':
--- crypto/asn1/x_cinf.org Thu Mar 20 22:16:08 2004
+++ crypto/asn1/x_cinf.cThu Mar 25 21:40:14 2004
@@ -97,7 +97,7 @@
[EMAIL PROTECTED] via RT [EMAIL PROTECTED] said:
i've added a second patch
http://arctic.org/~dean/crypto/openssl-0.9.8-CVS-bn-sse2-v2.patch -- the
second patch includes run-time detection of SSE2 and selects between two
implementations of bn_mul_add_words so that it can be used in a general
Verdon Walker [EMAIL PROTECTED] said:
I recently downloaded and compiled for Windows the 0.9.8 snapshot from
11-24-2003. I had a few minor problems of which you might want to be
aware:
.\crypto\bio\bss_file.c(218) : error C2065: 'fd' : undeclared
identifier
I've sent a patch for this some
Lutz Jaenicke via RT [EMAIL PROTECTED] said:
Hmm. Between OpenSSL 0.9.6 and 0.9.7, the following change was made
(see the corresponding util/libeay.num files):
OpenSSL_add_all_algorithms 508 EXIST::FUNCTION:
became
OpenSSL_add_all_algorithms 508
Lutz Jaenicke via RT [EMAIL PROTECTED] said:
Hmm. Between OpenSSL 0.9.6 and 0.9.7, the following change was made
(see the corresponding util/libeay.num files):
OpenSSL_add_all_algorithms 508 EXIST::FUNCTION:
became
OpenSSL_add_all_algorithms 508
Stephen Henson via RT [EMAIL PROTECTED] said:
Now if this works in one context but not another then I'd say that one
is picking up libeay32.dll from 0.9.6 and the other 0.9.7 or later. This
will depend on the Win32 DLL directories which IIRC depend on PATH, the
current directory and a few
Stephen Henson via RT [EMAIL PROTECTED] said:
Now if this works in one context but not another then I'd say that one
is picking up libeay32.dll from 0.9.6 and the other 0.9.7 or later. This
will depend on the Win32 DLL directories which IIRC depend on PATH, the
current directory and a few
MingW / gcc 3.3.1 / Win-XP / OpenSSL 0.9.8-dev (29 Oct 2003)
libeay32.dll is missing orinal 508 in it's export table.
c:\ pedump libeay32.dll:
exports table:
Name:libeay32.dll
Characteristics:
TimeDateStamp: 3FA1832D - Thu Oct 30 22:31:25 2003
Version:
The test programs bf_opts.exe and bfspeed.exe fails to
compile on MSVC/MingW befause of missing
struct tms :
--- crypto\bf\bf_opts.c.orig Wed Mar 07 12:00:27 2001
+++ crypto\bf\bf_opts.c Thu Oct 30 16:52:58 2003
@@ -63,10 +63,6 @@
#define TIMES
#endif
+#if defined(WIN32) ||
The test programs bf_opts.exe and bfspeed.exe fails to
compile on MSVC/MingW befause of missing
struct tms :
--- crypto\bf\bf_opts.c.orig Wed Mar 07 12:00:27 2001
+++ crypto\bf\bf_opts.c Thu Oct 30 16:52:58 2003
@@ -63,10 +63,6 @@
#define TIMES
#endif
+#if defined(WIN32) ||
Is _WINDLL (or OPENSSL_OPT_WINDLL) supposed to
be set by apps when linking to the OpenSSL import libs?
Or is it enough to simply link with the imports libs? The
docs didn't mention these flags.
BTW. The following test programs fails to link with the dynamic
versions of the libs:
From latest e_os.h (inside VxWORKS ifdef):
#define ioctlsocket(a,b,c) ioctl((a),(b),*(int*)(c))
Can this really be right? I mean using it in BIO_socket_ioctl()
expands to:
ioctlsocket (fd, type, *(int*)ptr);
I would assume VxWorks to expect a pointer in the 3rd arg
to it's ioctl(). If so,
Here is a revised patch using isatty() to check if stdin/stdin
is redirected. If they are allow setting binary mode. Otherwise
skip it as doing so prevents terminating a stuck app with ^C/^Break.
I can't see any use for making stdin binary while in interactive
mode except maybe in a password
Doug Kaufman [EMAIL PROTECTED] said:
In crypto/bio/bss_file.c, you change the way that binary or text is
chosen, and allow binary only if not going to stdout or or from stdin. I
think that the usual way to handle this (at least under DJGPP) is to use
isatty, and not allow binary if isatty
I didn't get any reaction on this patch. Isn't 32-bit MSDOS targets considered
good enough any longer?
The original message and patch is here:
http://marc.theaimsgroup.com/?l=openssl-devm=105943488203763w=2
--gv
__
OpenSSL
These are my patches to get openssl s_client working on
MSDOS / djgpp / Watt-32.
The assumtion that DOS in general can do select() on stdin/stdout
is wrong (allthough djgpp has some support for it, it's slow and clunky).
My patch uses kbhit() as Win32/WinCE does.
One other patch: I had to
These are my patches to get openssl s_client working on
MSDOS / djgpp / Watt-32.
The assumtion that DOS in general can do select() on stdin/stdout
is wrong (allthough djgpp has some support for it, it's slow and clunky).
My patch uses kbhit() as Win32/WinCE does.
One other patch: I had to
I've made my own makefile for a target that isn't supported
by OpenSSL (Open Watcom for Win32 to be exact).
I'm wondering about the define in e.g. crypto/des/des_opts.c:
#if !defined(OPENSSL_SYS_MSDOS) (!defined(OPENSSL_SYS_VMS) || ...
#define TIMES
#endif
That assumption is IMHO way to
Looks like the build for all Win32 targets (MSVC, MingW)
got broken with the introduction of the ./engines directory.
I looked at it, but failed to see where the dir is included.
Please, someone with more knowledge fix this.
--gv
Why is OPENSSL_NO_FP_API defined for all MS-DOS targets?
I assume it means No FILE pointer API. Isn't that situation covered
already by OPENSSL_NO_STDIO?
In e_os2.h:
/* Specials for I/O an exit */
#ifdef OPENSSL_SYS_MSDOS
# define OPENSSL_NO_FP_API
OPENSSL_NO_FP_API is already defined in
Richard Levitte - VMS Whacker [EMAIL PROTECTED] said:
The point with the change is that some exported header files depend on
OPENSSL_NO_FP_API (for example bio.h, but in total, it's checked in 15
of them). e_os2.h is an public header, e_os.h is not. Therefore, we
need to have that
Richard Levitte - VMS Whacker [EMAIL PROTECTED] said:
levitte Please name it. The reason that I ask you is that the changes you
levitte propose are already present in 0.9.7 and 0.9.8-dev.
Or is your patch a reverse patch?
No, not a reverse patch. The snapshot I diff'ed against was
The files.
./crypto/dsa/dsagen.c
./crypto/x509v3/v3conf.c
seems no longer used (reference from makefiles). But some functions have
wrong number of arguments. The files should IMHO be removed or corrected.
Here is a patch:
-
---
The files.
./crypto/dsa/dsagen.c
./crypto/x509v3/v3conf.c
seems no longer used (reference from makefiles). But some functions have
wrong number of arguments. The files should IMHO be removed or corrected.
Here is a patch:
-
---
Some test-files include a protype for read(). Unfortunately this protype doesn't
match the one in djgpp's unistd.h. Can we not removed this prototype?
The required system headers are included already I think.
Here is a patch to make it compile for djgpp:
The apps/s_socket.c compiles with a warning call to undefined function SHUTDOWN.
The sollution is to move #define USE_SOCKETS before including e_os.h:
--- apps/s_socket.c.orig Fri Nov 22 09:00:22 2002
+++ apps/s_socket.cThu Nov 28 14:42:56 2002
@@ -62,6 +62,8 @@
#include errno.h
The ms\mingw32.bat build fails with these undefines:
out/libcrypto.a(eng_all.o)(.text+0x9):eng_all.c: undefined reference to
`ENGINE_load_cswift'
out/libcrypto.a(eng_all.o)(.text+0xe):eng_all.c: undefined reference to
`ENGINE_load_chil'
out/libcrypto.a(eng_all.o)(.text+0x13):eng_all.c:
Here are some patches for MSDOS and djgpp using Watt-32 tcp/ip stack.
Patch against snapshot 11-Nov 2002.
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash
with stdlib.h
3.
What's up with the ftp.openssl.org server? It's been unreachable all day.
Gisle V.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Thanks a lot to Doug Kaufmann for the MSDOS patches for djgpp. But one thing I don't
understand. In ./crypto/bn/bn_mul.c:
#if defined(OPENSSL_NO_ASM) || !(defined(__i386) || defined(__i386__)) || \
defined(__DJGPP__) /* Assembler implementation exists only for x86 */
I haven't studied the
On Tue, 18 Jun 2002, Doug Kaufman wrote:
a chance to check this yet. Before doing this routinely for DJGPP, we
should probably verify that there are no instructions that won't work
on a 386 processor. Otherwise tha code won't be portable to many of
the low-powered machines (i.e. 386 and 486
I get unresolved symbol `EC_GROUP_get_group_by_name' when linking openssl.exe.
In what file should this function exist?
Gisle V.
__
OpenSSL Project http://www.openssl.org
Development Mailing
I can see the ftp://ftp.openssl.org has changed. Now there is no /snapshot directory.
Where are daily tar-balls uploaded?
Gisle V.
__
OpenSSL Project http://www.openssl.org
Development Mailing
I'm building OpenSSL on MSDOS, but have problems with long filenames.
My untar program silently overwrites e.g. ./crypto/engine/engine_err.c
with ./crypto/engine/engine_evp.c. Could you *please* make the engine-
files 8+3 compliant.
Gisle V.
Here are some patches for some files. Some files are unused (not in makefiles,
but in snapshot). All diffs are on diff -tBHu3 format against 19-Aug snapshot.
+++ ./crypto/des/cbc3_enc.c Tue Jul 31 10:13:42 2001
--- ./crypto/des/cbc3_enc.oldFri Aug 13 18:00:24 1999
@@ -70,13 +70,13 @@
Once again I'm getting unresolved symbols trying to compile the latest snapshot:
PKCS7_it
PKCS7_ATTR_SIGN_it
PKCS7_ATTR_VERIFY_it
PKCS7_ISSUER_AND_SERIAL_it
PKCS12_it
PKCS12_SAFEBAGS_it
PKCS12_AUTHSAFES_it
RSAPublicKey_it
RSAPrivateKey_it
Those are the missing symbols while linking openssl.exe.
Andy Polyakov [EMAIL PROTECTED] said:
BN_div_recp failed!
a=21CC27865629353755638C3726DF4C2D1C976729D1CD3C3FFC01039CE01B6687959E2BB84BAB54
D798D9873CAED7007AB955B025F799BDE5AE4C84D79DE7B35E7ED2A43
b=1
d:\net\openssl.095\binopenssl.exe version -a
OpenSSL 0.9.5beta2-dev 28 Feb 2000
On Tue, 29 Feb 2000, Ulf Möller wrote:
On Tue, Feb 29, 2000 at 09:36:53AM +0100, Gisle Vanem wrote:
I didn't use ./configure, but my single big homemade makefile
Please have a look at how it is done for Mingw32, and try to adopt
that do DJGPP. In fact, "perl Configure Mingw32&qu
Is anyone aware of a tcpdump extension parser for the SSL protocol?
The debugging available in OpenSSL is IMHO not well suited in
debugging the handshake and CONNECT transactions. I would
be nice to trace this in real-time using tcpdump.
Gisle V.
1 - 100 of 104 matches
Mail list logo
