- Original Message -
From: "Richard Levitte via RT" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: den 27 juni 2002 17:17
Subject: [openssl.org #111] Cross compilation assumption
>
> [[EMAIL PROTECTED] - Thu Jun 27 15:49:46 2002]:
>
> > Yes, I did notice t
- Original Message -
From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 21:30
Subject: Re: Hardware/ENGINE support for transport cryptos?
> From: [EMAIL PROTECTED]
>
> johan.adolfsson> Are there any pl
- Original Message -
From: Richard Levitte - VMS Whacker <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 21:30
Subject: Re: Hardware/ENGINE support for transport cryptos?
> From: [EMAIL PROTECTED]
>
> johan.adolfsson> Are there any pl
Are there any plans or thoughts about adding support for
hardware accelerated implementation of the common transport
cryptos such as RC4, 3DES etc. in libcrypto?
Any documentation available somewhere?
In a Linux system I guess the hardware related stuff will be in a
kernel driver, any thoughts
Hi all!
Here is a patch to better deal with crosscompiling in environments
where AR and RANLIB ar not called "ar" and "ranlib".
Typically a prefix or a suffix is added.
Any suggestions on how to set $ar and $ranlib in a better way then below?
The "elinux-aout-etrax100" target is not very well test
