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 crypto/engine/ get compiled in, but are
> unavailable. Those in engines/ get compiled as a shared library
> and are available.
> The problem seems to be that the Makefile for cryto/engine/ does
> not support making shared libraries.

It shouldn't. If an engine is to be built as shared object, then it
should be moved to ./engine.

> The engines in it will not
> get loaded if the library is build shared.
> The code in crypto/engine/eng_all.c: looks something like:
> void ENGINE_load_builtin_engines(void)
> {
> ENGINE_load_dynamic();
> #ifndef OPENSSL_NO_HW
> ENGINE_load_4758cca();
> ENGINE_load_aep();
> ENGINE_load_atalla();
> ENGINE_load_cswift();
> ENGINE_load_chil();
> ENGINE_load_nuron();
> ENGINE_load_sureware();
> ENGINE_load_ubsec();
> ENGINE_load_padlock();
> #endif
> ENGINE_load_cryptodev();
> ENGINE_load_gmp();
> #endif
> Most of those engines are in engines/ except for 2 of them:
> padlock and cryptodev. They are in crypto/engine/
> This means that currently padlock and cryptodev are not working
> in a shared version of the library.

For the record. As far as I understand eng_cryptodev is *BSD-specific
and is not expected to work on Linux in either case. I wonder how do
*BSD people solve this?

> I see 2 solutions to this:
> - Also provide them as shared libraries
> - Don't put them into the #ifndef OPENSSL_NO_STATIC_ENGINE

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 built-in engines even in
shared context."

2. If consensus is "yes for the option," which engines should be
available as builtins? Popular ones? Small ones? Self-contained ones?
Those addressing specific CPU capabilities directly? Those packager
wishes to favor? Those we decide on per-engine basis?

My vote is "per-engine basis based primarily on self-contained criteria
[i.e. when engine can operate without additional [user-land] component
provided by 3rd party, where 1st and 2nd parties are OS provider and
OpenSSL]." A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org