Until now, the engines in engines/ were only built as dynamicaly
loadable ones if shared libraries were built.
We not dissociate the two and can build dynamicaly loadable engines
even if we only build static libcrypto and libssl. This is controlled
with the option (enable|disable|no)-static-engine, defaulting to
no-static-engine.
Note that the engines in crypto/engine/ (dynamic and cryptodev) will
always be built into libcrypto.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The engine DSOs were named as if they were shared libraries, and could
end up having all sorts of fancy names:
Cygwin: cygFOO.dll
Mingw: FOOeay32.dll
Unix: libFOO.so / libFOO.sl / libFOO.dylib / ...
This may be confusing, since they look like libraries one should link
with at link time, when they're just DSOs.
It's therefore time to rename them, and do it consistently on all
platforms:
Cygwin & Mingw: FOO.dll
Unix: FOO.{so,sl,dylib,...}
Interestingly enough, the MSVC and VMS builds always did it this way.
Reviewed-by: Andy Polyakov <appro@openssl.org>
It seems that on some platforms, the perlasm scripts call the C
compiler for certain checks. These scripts need the environment
variable CC to have the C compiler command.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In build.info files, make the include directory in the build directory
absolute, or Configure will think it should be added to the source
directory top. Configure will turn it into a relative path if
possible.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Now that we have the foundation for the "unified" build scheme in
place, we add build.info files. They have been generated from the
Makefiles in the same directories. Things that are platform specific
will appear in later commits.
Reviewed-by: Andy Polyakov <appro@openssl.org>
