./Configure no-threads --prefix=/dev/env/DJDIR DJGPP
Just occured to me. What if end-user system doesn't have /dev catalog on
the current drive? Would an application succeed to open /dev/urandom$
even then? In other words wouldn't it more appropriate to check upon
urandom$ without *any* prefix
On Thu, 13 Jan 2005, Andy Polyakov wrote:
./Configure no-threads --prefix=/dev/env/DJDIR DJGPP
Just occured to me. What if end-user system doesn't have /dev catalog on
the current drive? Would an application succeed to open /dev/urandom$
even then? In other words wouldn't it more
On Mon, 3 Jan 2005, Doug Kaufman wrote:
On Mon, 3 Jan 2005, Andy Polyakov wrote:
I haven't audited the proposed patch yet, but I'd like you to explicitly
state what happens if the noise driver is not installed at end-user
system and provide a pointer to the driver (I know you've
On Tue, 4 Jan 2005, Andy Polyakov wrote:
Configure, openssl_fips_fingerprint, dbg_init and O_BINARY patches are
in now [both 0.9.7 and HEAD]. Compiler warnings will be addressed later.
As for -fno-strict-aliasing. I'd say it should rather be resolved in
source code, but [again] at some
Just couple of common words first. I realize that sometimes we can't
match the level of enthusiasm of our contributors [which might be
experienced as frustrating], but I want to emphasize that it does *not*
mean that the feedback is not appreciated. Please, keep up the good work
and bear with
-DDEVRANDOM=\/dev/urandom\\x24\ instead?
As for PATH=$TOP/apps\;$TOP\;$PATH in openssl_fips_fingerprint.
Configure, openssl_fips_fingerprint, dbg_init and O_BINARY patches are
in now [both 0.9.7 and HEAD]. Compiler warnings will be addressed later.
As for -fno-strict-aliasing. I'd say it should
I have tested current source code for the 0.9.8 version and the 0.9.7
version (fips and non-fips) with DJGPP. The attached patches allow
building under DJGPP. In addition to a few substantive fixes, I put in
a number of minor fixes to get rid of gcc warnings when compiled with
-W, such as putting
Just couple of common words first. I realize that sometimes we can't
match the level of enthusiasm of our contributors [which might be
experienced as frustrating], but I want to emphasize that it does *not*
mean that the feedback is not appreciated. Please, keep up the good work
and bear with
I added a default define for DEVRANDOM to the DJGPP
CFLAGs to enable use of the noise program, and had /dev/urandom$ read
in binary mode in rand_unix.c.
Eight \$ is not only ugly, but presumably has everything to do with
current amount of recursive invocations of make... Can we settle for
On Mon, 3 Jan 2005, Andy Polyakov wrote:
Just couple of common words first. I realize that sometimes we can't
match the level of enthusiasm of our contributors [which might be
experienced as frustrating], but I want to emphasize that it does *not*
mean that the feedback is not appreciated.
On Mon, 3 Jan 2005, Andy Polyakov wrote:
Eight \$ is not only ugly, but presumably has everything to do with
current amount of recursive invocations of make... Can we settle for
-DDEVRANDOM=\/dev/urandom\\x24\ instead?
As for PATH=$TOP/apps\;$TOP\;$PATH in openssl_fips_fingerprint. The
I have tested current source code for the 0.9.8 version and the 0.9.7
version (fips and non-fips) with DJGPP. The attached patches allow
building under DJGPP. In addition to a few substantive fixes, I put in
a number of minor fixes to get rid of gcc warnings when compiled with
-W, such as putting
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
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;
+
I just applied the patch and committed. Please test tomorrows
snapshot.
This ticket is now resolved.
[[EMAIL PROTECTED] - Tue Nov 12 22:31:27 2002]:
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
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.
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.
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, Gisle Vanem wrote:
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
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
20 matches
Mail list logo
