Hi,
It seems tht when building a shared version of the library, all
the engines in crypto/engine/ get compiled in, but are
unavailable. Those in engines/ get compiled as a shared library
and are available.
If you make a static library, or link against the static library
they do work as
On Mon, Jan 02, 2006 at 06:57:59PM +0100, Andy Polyakov wrote:
So let's make it a vote.
1. Should there be or not option for built-in engine in shared library
context, or should all engines without exclusion be available as
loadable modules?
My vote is there should be an option for
On January 3, 2006 11:27 am, Kurt Roeckx wrote:
On Mon, Jan 02, 2006 at 06:57:59PM +0100, Andy Polyakov wrote:
So let's make it a vote.
1. Should there be or not option for built-in engine in shared
library context, or should all engines without exclusion be available
as loadable
Hi,
It seems tht when building a shared version of the library, all
the engines in crypto/engine/ get compiled in, but are
unavailable. Those in engines/ get compiled as a shared library
and are available.
If you make a static library, or link against the static library
they do work as
Disclaimer. I personally is not as deeply involved in engine design,
e.g. I have no idea exactly why referred engines, eng_padlock and
eng_cryptodev reside in ./crypto/engine, while others in ./engine.
It seems tht when building a shared version of the library, all
the engines in
