There were cases where some input was absolute, and concatenating it
to the diretory to the source or build top could fail spectacularly.
Let's check the input first to see if it's absolute.
And while we're on the subject of checking if a file or dir spec is
absolute using file_name_is_absolute() has its own quirks on VMS,
where a logical name is considered absolute under most circumstances.
This is perfectly correct from a VMS point of view, but when parsing
the build.info files, we want single word file or directory names to
only be checked syntactically. A function isabsolute() that does the
right thing is the solution.
Reviewed-by: Rich Salz <rsalz@openssl.org>
version32.rc was not created on Windows. The if condition has been corrected.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
This option disables automatic loading of the crypto/ssl error strings in
order to keep statically linked executable file size down
Reviewed-by: Richard Levitte <levitte@openssl.org>
This commit provides the basis and core code for an auto initialisation
and deinitialisation framework for libcrypto and libssl. The intention is
to remove the need (in many circumstances) to call explicit initialise and
deinitialise functions. Explicit initialisation will still be an option,
and if non-default initialisation is needed then it will be required.
Similarly for de-initialisation (although this will be a lot easier since
it will bring all de-initialisation into a single function).
Reviewed-by: Richard Levitte <levitte@openssl.org>
It seems realpath() is quite buggy on VMS, or will at least give quite
surprising results. On the other hand, realpath() is the better on
Unix to clean out clutter like foo/../bar on Unix.
So we make out own function to get the absolute directory for a given
input, and use rel2abs() or realpath() depending on the platform
Configure runs on.
Issue reported by Steven M. Schweda <sms@antinode.info>
Reviewed-by: Andy Polyakov <appro@openssl.org>
common.tmpl will be used together with the template build file, and is
the engine that connects the information gathered from all the
build.info files with making the build file itself.
This file expects there to be a template section in the build file
template that defines a number perl functions designed to return
strings with appropriate lines for the build system at hand. The
exact functions, what they can expect as arguments and what output
they're expected to produce is documented in Configurations/README.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
File::Path::make_path didn't show up before File::Path 2.06 / perl v5.10.1.
Because we're trying to stay compatible with perl v5.10.0 and up,
it's better to use the legacy interface.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Some time ago, we had a ex_libs configuration setting that could be
divided into lflags and ex_libs. These got divided in two settings,
lflags and ex_libs, and the former was interpreted to be general
linking flags.
Unfortunately, that conclusion wasn't entirely accurate. Most of
those linking were meant to end up in a very precise position on the
linking command line, just before the spec of libraries the linking
depends on.
Back to the drawing board, we're diving things further, now having
lflags, which are linking flags that aren't depending on command line
position, plib_lflags, which are linking flags that should show up just
before the spec of libraries to depend on, and finally ex_libs, which
is the spec of extra libraries to depend on.
Also, documentation is changed in Configurations/README. This was
previously forgotten.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Add no-async option to Configure that forces ASYNC_NULL.
Related to RT1979
An embedded system or replacement C library (e.g. musl or uClibc)
may not support the *context APIs that are needed for async operation.
Compiles with musl. Ran unit tests, async tests skipped as expected.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
It turns out that the combination splitpath() could return an empty
string for the directory part. This doesn't play well with catdir().
Reviewed-by: Rich Salz <rsalz@openssl.org>
The "unified" build scheme revolves around small information files,
build.info, which each describe their own bit of everything that needs
to be built, using a mini-language described in Configurations/README.
The information in build.info file contain references to source files
and final result. Object files are not mentioned at all, they are
simply from source files. Because of this, all the *_obj items in
Configurations/*.conf are renamed to *_asm_src and the files listed
in the values are change from object files to their corresponding
source files. For the sake of the other build schemes, Configure
generates corresponding *_obj entries in %target.
Furthermore, the "unified" build scheme supports having a build
directory tree separate from the source directry tree.
All paths in a build.info file is assumed to be relative to its
location, either within the source tree or within the build tree.
Reviewed-by: Andy Polyakov <appro@openssl.org>
When the target is {something}-icc, we're doing some extra checks of
the icc compiler. However, all such targets were cleaned away in
March 2015, so this Configure section is dead code.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There was an unused macro in ssl_locl.h that used an internal
type, so I removed it.
Move bio_st from bio.h to ossl_type.h
Reviewed-by: Andy Polyakov <appro@openssl.org>
The lflags configuration had a weird syntax with a % as separator. If
it was present, whatever came before ended up as PEX_LIBS in Makefile
(usually, this is LDFLAGS), while whatever came after ended up as
EX_LIBS.
This change splits that item into lflags and ex_libs, making their use
more explicit.
Also, PEX_LIBS in all the Makefiles are renamed to LDFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Many options for supporting optimizations for legacy crypto on legacy
platforms have been removed. This simplifies the source code and
does not really penalize anyone.
DES_PTR (always on)
DES_RISC1, DES_RISC2 (always off)
DES_INT (always 'unsigned int')
DES_UNROLL (always on)
BF_PTR (always on) BF_PTR2 (removed)
MD2_CHAR, MD2_LONG (always 'unsigned char')
IDEA_SHORT, IDEA_LONG (always 'unsigned int')
RC2_SHORT, RC2_LONG (always 'unsigned int')
RC4_LONG (only int and char (for assembler) are supported)
RC4_CHUNK (always long), RC_CHUNK_LL (removed)
RC4_INDEX (always on)
And also make D_ENCRYPT macro more clear (@appro)
This is done in consultation with Andy.
Reviewed-by: Andy Polyakov <appro@openssl.org>
A mistake was made and the setting of this config variable got
reverted to an older behavior. This restores the latest.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Enhances the routines in OpenSSL::Test::Utils for checking disabled
stuff to get their information directly from Configure instead of
'openssl list -disabled'.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
- Small rearrangement of the TABLE and HASH printouts, and adding
printout of the "build_scheme" item
- Renamed "engines_obj" to "padlock_obj"
- Moved the runs of dofile down... it didn't quite make sense to have
that in the middle of a printout
Reviewed-by: Rich Salz <rsalz@openssl.org>
Now that we're using templates, we should warn people not to edit the
resulting file. We do it through util/dofile.pl, which is enhanced
with an option to tell what file it was called from. We also change
the calls so the template files are on the command line instead of
being redirected through standard input. That way, we can display
something like this (example taken from include/openssl/opensslconf.h):
/* WARNING: do not edit! */
/* Generated by Configure from include/openssl/opensslconf.h.in */
Reviewed-by: Rich Salz <rsalz@openssl.org>
It is time for Makefile.org to fold into the new regime and have a run
through util/dofile.pl. This forces some information out of there and
into Configure, which isn't a bad thing, it makes Configure
increasingly the center of build information, which is as it should
be.
A few extra defaults were needed in the BASE template to get rid of
warnings about missing values.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Move opensslconf.h.in to include/openssl.
Split off DES,BN,RC4 stuff into separate header file
templates in crypto/include/internal/*_conf.h.in
Reviewed-by: Richard Levitte <levitte@openssl.org>
Now that configdata.pm is the centre of information, use that instead
of Makefile to figure out reconfiguration parameters. This will help
future development with different Makefile file names.
The code to read necessary configuration data from Makefile is retained
for an easy transition to configdata.pm based information gathering. It
will be removed later on.
This change includes moving the variable $cross_compile_prefix to %config.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
The turn has come to have crypto/opensslconf.h.in get run through
util/dofile.pl. The consequence is that a large number of variables
get moved to the %config table.
Also, the string variables $openssl_*, which were populated with cpp
lines, all being of the form "#define SOMETHING", were converted into
ARRAY refs in %config values, containing just the list of macros to be
defined.
Reviewed-by: Rich Salz <rsalz@openssl.org>
For this adaptation, the variables $options and $version needed to
move to %config in Configure, and why not move all other variables
holding diverse version numbers at the same time?
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
apps/CA.pl and tools/c_rehash are built from template files. So far,
this was done by Configure, which created its own problems as it
forced everyone to reconfigure just because one of the template files
had changed.
Instead, have those files created as part of the normal build in apps/
and in tools/.
Furthermore, this prepares for a future where Configure may produce
entirely other build files than Makefile, and the latter can't be
guaranteed to be the holder of all information for other scripts.
Instead, configdata.pm (described below) becomes the center of
configuration information.
This introduces a few new things:
%config a hash table to hold all kinds of configuration data
that can be used by any other script.
configdata.pm a perl module that Configure writes. It currently
holds the hash tables %config and %target.
util/dofile.pl a script that takes a template on STDIN and outputs
the result after applying configuration data on it.
It's supposed to be called like this:
perl -I$(TOP) -Mconfigdata < template > result
or
perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result
Note: util/dofile.pl requires Text::Template.
As part of this changed, remove a number of variables that are really
just copies of entries in %target, and use %target directly. The
exceptions are $target{cflags} and $target{lflags}, they do get copied
to $cflags and $lflags. The reason for this is that those variable
potentially go through a lot of changes and would rather deserve a
place in %config. That, however, is for another commit.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
It's time for print_table_entry to get a bit of refreshment. The way it
was put together, we needed to maintain the list of known configuration
keys of interest twice, in different shapes. This is error prone, so
move the list of strings to a common list for all printing cases, and
use simple formatting of lines to do the actual printout based on that
list.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Time to get rid of @MK1MF_Builds and introduce a more flexible
'build_scheme' configuration key. Its value may be a string or an
array of strings, meaning we need to teach resolve_config how to
handle ARRAY referenses.
The build scheme is a word that selects a function to create the
appropriate result files for a certain configuration. Currently valid
build schemes aer "mk1mf" and "unixmake", the plan is however to add
at least one other for a more universal build scheme.
Incidently, this also adds the functions 'add' and 'add_before', which
can be used in a configuration, so instead of having to repeatedly
write a sub like this:
key1 => sub { join(" ", @_, "myvalues"); },
key2 => sub { join(" ", "myvalues", @_); },
one could write this:
key1 => add(" ", "myvalues"),
key2 => add_before(" ", "myvalues"),
The good point with 'add' and 'add_before' is that they handle
inheritances where the values are a misture of scalars and ARRAYs. If
there are any ARRAY to be found, the resulting value will be an ARRAY,
otherwise it will be a scalar with all the incoming valued joined
together with the separator given as first argument to add/add_before.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Move the documentation of the target configuration form to
Configurations/README.
Move initial assembler object templates to
Configurations/00-BASE-templates.conf.
Furthermore, remove all variables containing the names of the
non-assembler object files and make a BASE template of them instead.
The values from this templates are used as defaults as is. The
remaining manipulation of data when assembler modules are used is done
only when $no_asm is false.
While doing this, clean out some other related variables that aren't
used anywhere.
Also, we had to move the resolution of the chosen target a bit, or the
function 'asm' would never catch a true $no_asm... this hasn't
mattered before we've moved it all to the BASE template, but now it
does.
At the same time, add the default for the 'unistd' key to the BASE
template.
Reviewed-by: Rich Salz <rsalz@openssl.org>
--prefix is now exclusively used for software and manual installation.
--openssldir is not exclusively used as a default location for certs,
keys and the default openssl.cnf.
This change is made to bring clarity, to have the two less
intertwined, and to be more compatible with the usual ways of software
installation.
Please change your habits and scripts to use --prefix rather than
--openssldir for installation location now.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
