Purpose of build_all_generated is to execute all the rules that require
perl, so that one can copy the tree to system with compiler but without
perl. This commit removes last dependencies on perl.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5929)
Computing the value of the GENERATED variable in the build file
templates is somewhat overcomplicated, and because of possible
duplication errors, changes are potentially error prone.
Looking more closely at how this list is determined, it can be
observed that the exact list of files to check is consistently
available in all the values found in the %unified_info tables
'depends', 'sources' and 'shared_sources', and all that's needed is to
filter those values so only those present as keys in the 'generate'
table are left.
This computation is also common for all build files, so due to its
apparent complexity, we move it to common0.tmpl, with the result left
in a global variable (@generated), to be consumed by all build file
templates.
common0.tmpl is included among the files to process when creating
build files, but unlike common.tmpl, it comes first of all.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5930)
HP-UX provides sockets symbols with incompatible prototypes under same
name. This caused problems in 64-bit builds. Additional macros force
unambiguous symbols with unambiguous prototypes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5742)
We started using $(CPP) instead of $(CC) -E, with the assumption that
CPP would be predefined. This is, however, not always true, and
rather depends on the 'make' implementation. Furthermore, on
platforms where CPP=cpp or something else other than '$(CC) -E',
there's a risk that it won't understand machine specific flags that we
pass to it. So it turns out that trying to use $(CPP) was a mistake,
and we therefore revert that use back to using $(CC) -E directly.
Fixes#5867
Note: this affects config targets that use Alpha, ARM, IA64, MIPS,
s390x or SPARC assembler modules.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5872)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5625)
The LIBZ macro definition was already quoted in BASE_windows, then got
quotified once more in windows-makefile.tmpl. That's a bit too much
quotations, ending up with the compiler being asked to define the
macro |"LIBZ=\"ZLIB1\""| (no, not the macro LIBZ with the value
"ZLIB1"). This is solved by removing the extra quoting in
BASE_windows.
Along with this, change the quotation of macro definitions and include
file specification, so we end up with things like -I"QuotedPath" and
-D"Macro=\"some weird value\"" rather than "-IQuotedPath" and
"-DMacro=\"some weird value\"".
Fixes#5827
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5833)
picker() is type agnostic, but its output consumer is not. Or rather
it doesn't work if picker() picks nothing when consumer expects
array. So ensure array is returned when array is expected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5770)
This is quick-n-dirty ad-hoc solution, the problem asks for more
elegant one...
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5755)
.res files weren't treated consistently. They weren't included at all
in the build of a shared library, and were named inconsistently; .res
sometimes, and .res.o otherwise. Now we standardise it to .res.o,
which is the recommended way with GNU tools.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5730)
Although it deviates from the actual prototype of DSO_dsobyaddr(), this
is now ISO C compliant and gcc -Wpedantic accepts the code.
Added DATA segment checking to catch ptrgl virtual addresses. Avoid
memleaks with every AIX/dladdr() call. Removed debug-fprintf()s.
Added test case for DSO_dsobyaddr(), which will eventually call dladdr().
Removed unecessary AIX ifdefs again.
The implementation can only lookup function symbols, no data symbols.
Added PIC-flag to aix*-cc build targets.
As AIX is missing a dladdr() implementation it is currently uncertain our
exit()-handlers can still be called when the application exits. After
dlclose() the whole library might have been unloaded already.
Signed-off-by: Matthias Kraft <makr@gmx.eu>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5668)
Since they intend to omit gcc, it's more appropriate to simply detect
if there is NDK's clang on PATH, as opposite to requiring to specify it
with CC=clang (and looking for it on PATH).
Also detect NDK version and default to armv7-a for NDK>16.
Address failure to recognize -D__ADNDROID_API__=N in CPPFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)
In the end, it's more efficient to only have one perl instance (that
loads configdata.pm) dealing with dependency files than running one
(that still loads configdata.pm) for each such file.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5631)
It seems that only gcc -MMD produces dependency files that are "sane"
for our needs. For all other methods, some post processing is needed:
- 'makedepend' (Unix) insists that object files are located in the
same spot as the source file.
- 'cl /Zs /showIncludes' (Visual C) has "Note: including file: " where
we'd like to see the object.
- 'CC/DECC' (VMS) insists that the object file is located in the
current directory, i.e. it strips away all directory information.
So far, we've managed this (except for the VMS case) with individual
uncommented perl command lines directly in the build file template.
We're now collecting these diverse hacks into one perl script that
takes an argument to tell what kind of input to expect and that
massages whatever it gets on STDIN and outputs the result on STDOUT.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)
The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian [0]. So far so good.
Unless there are different suggestions how to do this, I would keep it.
However since the target name does not start with `linux', the build
system does not enable the afalg engine. So in order to get enabled, I
added a
`enable => [ "afalgeng" ],'
to the generic linux config which sets it explicit (as suggested by
Richard Levitte). Having this set, we can check for it instead matching
the target name.
[0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5169)
We have '--strict-warnings' for this kind of stuff... also, user
flags are added last, so this overrides any warning supression
--strict-warnings may put in place (for good reasons).
Fixes#5609
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5612)
Move Android targets to separate file, automate sysroot setup and
add support for NDK 16.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5589)
With the help of the perl script util/add-depends.pl, which takes all
its information directly from configdata.pm, the dependency adding
procedure can be streamlined for all support platforms.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5606)
So far assembly modules were built as .pl->.S->.s followed by .s->.o.
This posed a problem in build_all_generated rule if it was executed
on another computer. So we change rule sequence to .pl->.S and then
.S->.s->.o.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5573)
$target{build_scheme} consists of fixed number of elements with 3rd
element denoting VC install-path "flavour", i.e. where to install things.
Instead of looking at 3rd, let's look at last. This allows to override
flavour from template in a simple way.
Configurations/10-main.conf: define generic "flavour" in VC-common
template. Since VC-W32 was the only recognized "flavour", remove
"flavour" definitions from all targets/templates, but VC-WIN32. And
rename VC-W32 to VC-WOW.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5502)
We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up. Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.
So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)
Travis-ci log output is huge and overflows internal travis-ci view,
which makes it hard to find errors.
Redirect some output to a file and dump it only if it fails.
Remove "v" option from tar that builds and extracts the srcdist.
While running the tests manually, some non-POSIX (bashisms) with ==
vs = came to light.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5555)
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rather than in
addition to them, it gets confusing to have similar or exactly the
same attributes working with different semantics on Unix.
So we rename those by changing the prefix dso_ to module_, and having
those work just like the shared_ attributes, but for DSOs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
We have never used these variables with the Unix Makefile, and there's
no reason for us to change this, so to avoid confusion, we remove them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5545)
-fno-common was removed for all Darwin targets in
0c8734198d with rationale "it's either
'ranlib -c' or '-fno-common'." However, it's still absolutely required
in 32-bit darwin-ppc-cc. And when trying things out I didn't quite
see why it was formulated as one-or-another choice, as 'ranlib -c'
shouldn't [and doesn't] have problems with object modules without
commons. [Well, to be frank, I didn't manage to reproduce the problem
the modification was meaning to resolve either...]
Reviewed-by: Rich Salz <rsalz@openssl.org>
With this, we introduce the make variable 'libdir', which differs from
'LIBDIR' not only in casing, but also by being the absolute path to
the library installation directory. This variable is intentionally
compatible with the GNU coding standards.
When --libdir is given an absolute path, it is considered as a value
according to GNU coding standards, and the variables LIBDIR and libdir
will be this:
LIBDIR=
libdir=/absolute/path
When --libdir is given a relative path (just the name of the desired
library directory), or not given at all, it is considered as a
"traditional" OpenSSL value, and the variables LIBDIR and libdir will
be this:
LIBDIR=relativepath
libdir=$(INSTALLTOP)/$(LIBDIR)
Fixes#5398
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5446)
The reason for this is that some of the C flags affect built in macros
that we may depend on.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5436)
If the configured value is the empty string, give them a sane default.
Otherwise, give them the configured value prefix with $(CROSS_COMPILE)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
It was inconsistent to see this specific command have
'$(CROSS_COMPILE)' in its value when no other command did.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
In previous OpenSSL versions, this letter was part of the make
variable AR. However, following the usual convention (read: GNU),
this letter is supposed to be part of ARFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5386)
Avoid using crypto/modes/ghash-ia64.s, as it uses features that are
explicitely prohibited on VMS.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)
The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in
addition to CFLAGS and so on. This works without problem on Unix and
Windows, where options with different purposes (such as -D and -I) can
appear anywhere on the command line and get accumulated as they come.
This is not necessarely so on VMS. For example, macros must all be
collected and given through one /DEFINE, and the same goes for
inclusion directories (/INCLUDE).
So, to harmonize all platforms, we repurpose make variables starting
with LIB_, DSO_ and BIN_ to be all encompassing variables that
collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES,
INCLUDES and so on together with possible config target values
specific for libraries DSOs and programs, and use them instead of the
general ones everywhere.
This will, for example, allow VMS to use the exact same generators for
generated files that go through cpp as all other platforms, something
that has been impossible to do safely before now.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)
Instead of having the knowledge of the exact flags to run the C
preprocessor only and have it output on standard output in the deeper
recesses of the build file template, make it a config parameter, or
rely on build CPP in value ('$(CC) -E' on Unix).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5356)
All VMS config targets were literally copies of each other, only
differing in what argument the parameter seeking function vms_info()
received (the pointer size).
This could be hugely simplified by letting vms_info() detect what
pointer size was desired from the desired config target name instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5364)
It was a bit absurd to have this being specially handled in the build
file templates, especially that we have the 'includes' attribute.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5296)
Configurations/descrip.mms.tmpl didn't treat the includes config
attribute very well. In fact, it didn't treat it at all!
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5295)
If a module is disablable (i.e. can be configured with 'no-FOO'), the
resulting header file needs to be guarded with a check of the
corresponding OPENSSL_NO_FOO. While this seem fairly innocuous, it
has an impact on the information in util/*.num, generated by mkdef.pl.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5275)
Most modules are direct implementations of openssl application
sub-commands, but some constitute a support library, which can be used
by more than one program (and is, incidently, by test/uitest).
For practical purposes, we place the support library modules in a
private, static library.
Finally, there are some modules that don't have direct references in
the rest of the apps code, but are still crucial. See them as some
kind of extra crt0 or similar for your platform.
Inspiration from David von Oheimb
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5222)
For proper escaping, we need the direct perl variable values, not a
make variable reference.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5196)
C++ flags got the same config target value as C flags, but then
nothing else happened while C flags get all kinds of stuff added to
them (especially when --strict-warnings is used).
Now, C++ flags get the exact same treatment as C flags. However, this
only happens when a C++ compiler is specified, to avoid confusing
messages about added C++ flags.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5181)
vc_wince_info()->{defines} was left around, when it should be
vc_wince_info()->{cppflags}
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5182)
There were a small number that inherited no BASE, the now inherit
BASE_unix.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
Ideally, each config target should inherit a base to get their
platform specific defaults. Unfortunately, that is currently not the
case, so we duplicate the Unixly defaults from the BASE_unix template
into the DEFAULT template.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
Default values belong in the DEFAULT config target template, in
Configurations/00-base-templates.conf.
This isn't a complete move, but takes care of the most blatant
examples.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
Support the following "make variables":
AR (GNU compatible)
ARFLAGS (GNU Compatible)
AS (GNU Compatible)
ASFLAGS (GNU Compatible)
CC (GNU Compatible)
CFLAGS (GNU Compatible)
CXX (GNU Compatible)
CXXFLAGS (GNU Compatible)
CPP (GNU Compatible)
CPPFLAGS (GNU Compatible)
CPPDEFINES List of CPP macro definitions. Alternative for -D
CPPINCLUDES List of CPP inclusion directories. Alternative for -I
HASHBANGPERL Perl invocation to be inserted after '#!' in public
perl scripts.
LDFLAGS (GNU Compatible)
LDLIBS (GNU Compatible)
RANLIB Program to generate library archive index
RC Program to manipulate Windows resources
RCFLAGS Flags for $(RC)
RM (GNU Compatible)
Setting one of these overrides the corresponding data from our config
targets. However, flags given directly on the configuration command
line are additional, and are therefore added to the flags coming from
one of the variables above or the config target.
Fixes#2420
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
C preprocessor flags get separated from C flags, which has the
advantage that we don't get loads of macro definitions and inclusion
directory specs when linking shared libraries, DSOs and programs.
This is a step to add support for "make variables" when configuring.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5177)
This ensures that only one set of includes is associated with each
object file, reagardless of where it's used.
For example, if apps/build.info has this:
SOURCE[openssl]=foo.c
INCLUDE[openssl]=.. ../include
and test/build.info has this:
SOURCE[footest]=../apps/foo.c
INCLUDE[footest]=../include
The inclusion directories used for apps/foo.o would differ depending
on which program's dependencies get generated first in the build file.
With this change, all those INCLUDEs get combined into one set of
inclusion directories tied to the object file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5153)
Since libssl requires libcrypto and libcrypto.pc already has
Libs.private set exactly the same, there's no reason to repeat it in
libssl.pc.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5134)
Even -pthread gets treated that way. The reason to do this is so it
ends up in 'Libs.private' in libcrypto.pc.
Fixes#3884
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5134)
So far, we've placed all extra library related flags together, ending
up in the make variable EX_LIBS. This turns out to be problematic, as
for example, some compilers don't quite agree with something like
this:
cc -o foo foo.o -L/whatever -lsomething
They prefer this:
cc -L/whatever -o foo foo.o -lsomething
IBM's compiler on OS/390 is such a compiler that we know of, and we
have previously handled that as a previous case.
The answer here is to make a more general solution, where linking
options are divided in two parts, where one ends up in LDFLAGS and
the other in EX_LIBS (they corresponds to what is called LDFLAGS and
LDLIBS in the GNU world)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5033)
The uClinux targets included some attributes that would result in
circular references of CFLAGS and LDCLAGS.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5034)
Similar to commit 17b602802114d53017ff7894319498934a580b17(
"Remove extra `the` in SSL_SESSION_set1_id.pod"), this commit removes
typos where additional 'the' have been added.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4999)
Following the changes that removed Makefile.shared, we also changed
the generation of .def / .map / .opt files from ordinals more
explicit, removing the need to the "magic" ORDINALS declaration.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4993)
The simplifications that were made when Makefile.shared was removed
didn't work quite right. Also, this is what we do on Unix and Windows
anyway, so this makes us more consistent across all platforms.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4982)
Ignore libssl.map/libcrypto.map instead of ssl.map/crypto.map
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4932)
Remove some config attributes that just duplicate values that are
already there in other attributes.
Remove the special runs of mkdef.pl and mkrc.pl from build file
templates, as these are now done via GENERATE statements in
build.info.
Remove all references to ordinal files from build file templates, as
these are now treated via the GENERATE statements in build.info.
Also remove -shared flags and similar that are there in shared-info.pl
anyway. (in the case of darwin, it's mandatory, as -bundle and
-dynamiclib don't mix)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
Because this also includes handling all sorts of non-object files when
linking a program, shared library or DSO, this also includes allowing
general recognition of files such as .res files (compiled from .rc
files), or .def / .map / .opt files (for export and possibly
versioning of public symbols only).
This does mean that there's a tangible change for all build file
templates: they must now recognise and handle the `.o` extension,
which is used internally to recognise object files internally. This
extension was removed by common.tmpl before this change, but would
mean that the platform specific templates wouldn't know if "foo.map"
was originally "foo.map.o" (i.e. an object file in its own right) or
"foo.map" (an export definition file that should be treated as such,
not as an object file).
For the sake of simplifying things, we also modify util/mkdef.pl to
produce .def (Windows) and .opt (VMS) files that don't need additional
hackery.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
This will replace the use of Makefile.shared
This also means a small adjustment on how the attributes dso_cflags,
dso_cxxflags and dso_lflags are treated. They were previously treated
as an extension to shared_cflag, shared_cxxflag and shared_ldflag, but
they should really be regarded as alternatives instead, for example
for darwin, where -dynamiclib is used for shared libraries and -bundle
for DSOs.
We take the opportunity to clean out things that are redundant or
otherwise superfluous (for example the check of GNU ld on platforms
where it never existed).
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
It will return the last expression from the input file.
We also use this in read_config, which slightly changes what's
expected of Configurations/*.conf. They do not have to assign
%targets specifically. On the other hand, the table of configs MUST
be the last expression in each of those files.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)
This way, any of the relevant environment variables for the platform
being configured are preserved and don't have to be recalled manually
when reconfiguring.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4818)
This small change in the Unix template and shared library build
scripts enables building "variant" shared libraries. A "variant"
shared library has a non-default SONAME, and non default symbol
versions. This makes it possible to build (say) an OpenSSL 1.1.0
library that can coexist without conflict in the same process address
space as the system's default OpenSSL library which may be OpenSSL
1.0.2.
Such "variant" shared libraries make it possible to link applications
against a custom OpenSSL library installed in /opt/openssl/1.1 or
similar location, and not risk conflict with an indirectly loaded
OpenSSL runtime that is required by some other dependency.
Variant shared libraries have been fully tested under Linux, and
build successfully on MacOS/X producing variant DYLD names. MacOS/X
Darwin has no symbol versioning, but has a non-flat library namespace.
Variant libraries may therefore support multiple OpenSSL libraries
in the same address space also with MacOS/X, despite lack of symbol
versions, but this has not been verified.
Variant shared libraries are optional and off by default.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We had /WX (treat warnings as errors) in VC-WIN32 for long time. At
some point it was somehow omitted. It's argued that it allows to
keep better focus on new code, which motivates the comeback...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4721)
Around 138 distinct errors found and fixed; thanks!
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)
HP-UX make doesn't recognize $< in explict target rules, only in
inference ones such as .c.o.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4697)
It turns out that (some?) fuzzers can read a dictionary of OIDs,
so we generate one as part of the usual 'make update'.
Fixes#4615
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/4637)
Names were not removed.
Some comments were updated.
Replace Andy's address with openssl.org
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4516)
RESULT_D can be used to provide a separate directory for test results.
Let's use that to separate them from other files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4507)
Detect clang even if it's disguised, e.g. cross-compiler or invoked by
explicit path name, and add the option based on that.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4383)
We changed directory to the wrong directory.
This change also separates the preparation phase from the tarball
building phase.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4179)
submodules are directories that we don't want in our tarballs, so
avoid them.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4178)
$(SHLIB_MAJOR).$(SHLIB_MINOR) is really a synonym for
$(SHLIB_VERSION_NUMBER), and is therefore an added complexity,
so better to use $(SHLIB_VERSION_NUMBER) directly. SHLIB_MAJOR and
SHLIB_MINOR are now unused, but are kept around purely as information
in case someone relies on their existence.
At the same time, add support for custom shared library extensions
with the three new Makefile variables SHLIB_EXT, SHLIB_EXT_SIMPLE and
SHLIB_EXT_IMPORT. By default, they hold the variants of shared
library extensions we support. On mingw and cygwin, SHLIB_EXT_IMPORT
is defined; on all other Unix platforms, it's empty.
An example to get shared libraries with a slightly different SOVER name:
$ make SHLIB_EXT='.$(SHLIB_VERSION_NUMBER).so'
Fixes#3902
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3964)
Makefile.shared was designed to figure out static library names,
shared library names, library version compatibility, import library
names and the like on its own. This was a design for pre-1.1.0
OpenSSL because the main Makefile didn't have all that knowledge.
With 1.1.0, the situation isn't the same, a lot more knowledge is
included in the main Makefile, and while Makefile.shared did things
right most of the time (there are some corner cases, such as the
choice of .sl or .so as DSO extension on some HPUX versions), there's
still an inherent fragility when one has to keep an eye on
Makefile.shared to make sure it produces what the main Makefile
produces.
This change simplifies Makefile.shared by removing all its
"intelligence" and have it depend entirely on the input from the main
Makefile instead. That way, all the naming is driven from
configuration data.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3983)
Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3691)
This new target is used to build all generated files and only that.
This can be used to prepare everything that requires things like perl
for a system that lacks perl and then move everything to that system
and do the rest of the build there.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3695)
Because apps/progs.h isn't configuration agnostic, it's not at all
suited for 'make update' or being versioned, so change it to be
dynamically generated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3688)
Fix test for "documenting private functions"
And add -p flag to doc-nits recipe
Mark when things were deprecated, if doc'd as such
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3624)
The list of programs hit nmake's maximum line length, so we split up the
line in smaller chunks.
Fixes#3634
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3636)
Run perltidy on util/mkerr
Change some mkerr flags, write some doc comments
Make generated tables "const" when genearting lib-internal ones.
Add "state" file for mkerr
Renerate error tables and headers
Rationalize declaration of ERR_load_XXX_strings
Fix out-of-tree build
Add -static; sort flags/vars for options.
Also tweak code output
Moved engines/afalg to engines (from master)
Use -static flag
Standard engine #include's of errors
Don't linewrap err string tables unless necessary
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3392)
As far as I know, there is no MMS / MMK with parallellism today.
However, it might be added in the future (perhaps in MMK at least), so
we may as well prepare for it now.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3282)
jom is an nmake clone that does parallell building, via the same -j
argument as GNU make. To make it work, we need to apply the same
dependeency build up as done in 27c40a9317Fixes#3272
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3277)
When building object files for libraries, information whether the
library would be installed or not wasn't passed down to the object
file building rules.
Also, make it so settings like |no_inst_lib_cflags| can be the empty
string.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3247)
It turns out that /DSF didn't do any good for our purposes. Instead,
remove the CALL_DEBUG flag from any image we link. This ensures that
we can have debugging information in the image files, but don't
automatically end up in a debugging session upon image activation.
Unfortunately, this means the CALL_DEBUG must be turned on when there
is a need to run with the debugger activated, and to turn it off when
done. This has been documented in NOTES.VMS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2957)
That makes it possible to run images without automagically ending up
in a debug session, while still being able to debug when required.
All .DSF files must reside in the same directory to be useful.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2947)
Add 2017 copyright year
Add missing typedef to NAME
Remove ec(7) and bn(7) doc links
Remove .pod link errors, bogus links, make a few typo corrections
Fix some typo's in links and some missing items.
Don't link to C runtime functions (See OPENSSL_malloc for example/precedent)
Document ASN1_tag2str(), add a few typedef's that were missing from NAME
Update doc-nits target; addresses
https://github.com/openssl/openssl/pull/1900#issuecomment-259943891,
Merge check-doc-links into find-doc-nits; if run regularly, would have found
https://github.com/openssl/openssl/pull/2825
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2862)
For each platform, we may need to perform some basic checks to see
that available tools perform as we expect them.
For the moment, the added checkers test that Perl gives the expected
path format. This should help MingW users to see if they run an
appropriate Perl implementation, for example.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2851)
One of the reasons for why masm/ml64 is not [fully] supported is that
it's problematic to support multiple versions. But latest one usually
works and/or it's lesser problem to make it work. So idea here is to
have a "whistle" when it breaks, so that problems can be evaluated as
they emerge. It's kind of "best effort" thing, as opposite to "full
support".
Reviewed-by: Richard Levitte <levitte@openssl.org>
'linux-x86' is similar to 'linux-x86_64' but uses -m32 rather than -m64.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1924)
Now that we can link specifically with static libraries, the immediate
need to split ppccap.c (and eventually other *cap.c files) is no more.
This reverts commit e3fb4d3d52.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Very simply, support having the .a extension to denote depending on
static libraries. Note that this is not supported on native Windows
when building shared libraries, as there is not static library then,
just an import library with the same name.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1889)
Instead of enumerating exactly those files in test/ that include
../ssl/ssl_locl.h, assume they all do.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1891)
Having that code in one central object file turned out to cause
trouble when building test/modes_internal_test.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1883)
For consistency, it's better to use the perl that was specified to
Configure last time it was called.
Use case:
perl v5.8.8 was first along $PATH, perl v5.22.2 was available and
specified as: PERL=/opt/local/bin/perl ./config. When make wanted to
reconfigure and called './Configure reconf', configuration broke down,
complaining about a perl that's too old.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1884)
If zlib-dynamic was given but not --with-zlib-lib, LIBZ was defined to
the empty string. Instead, give it the default "ZLIB1".
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1772)
VMS only unloads shared libraries at process rundown, so tell the
OpenSSL code so by pretending we linked with -znodelete.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1862)
Since the local symbol table is looked up before the global symbol
table, 'arch' assigned in the local symbol table of the DCL where MMS
is called would be seen before the 'arch' defined in descrip.mms.
Assigning it to the local symbol table in descrip.mms removes that
issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1853)
The logic around avoiding MULDEF warnings was flawed. Simplifying it
makes it better.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1846)
Pre 1.1.0, 'make test' would set the environment variable
OPENSSL_DEBUG_MEMORY to "on". This got lost when translating the old
build files to the new templates. This changes reintroduces that
variable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1840)
gcc is kinder, it silently passes quite a few flags to ld, while clang
is stricter and wants them prefixed with -Wl,
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1836)
The Unix and Windows linkers appear to simply ignore if any symbol is
defined multiple times in different object files and libraries.
The VMS linker, on the other hand, warns about it, loud and clear. It
will still create the executable, but does so screaming. So we
complicate things by saving the linker output, look through all the
errors and warnings, and if they are only made up of %LINK-W-MULDEF,
we let it pass, otherwise we output the linker output and raise the
same exit code we got from the linker.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1789)
Instead of deliberately leaking a reference to ourselves, use nodelete
which does this more neatly. Only for Linux at the moment.
Reviewed-by: Tim Hudson <tjh@openssl.org>
VC-noCE-common and VC-WIN64-common were missing this line:
template => 1,
Fixes GH#1809
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1811)
Move manpages to manX directories
Add Windows/VMS install fix from Richard Levitte
Update README
Fix typo's
Remove some duplicates
Reviewed-by: Richard Levitte <levitte@openssl.org>
The current version of the VMS compiler provides C99 features,
strictly language wise. Unfortunately, even the most recent standard
library isn't fully updated for that standard, so we need to use an
earlier standard that the compiler supports.
Most importantly, this affects the __STDC_VERSION__ value, which the
compiler unfortunately currently defaults to 199901L. With this
change we won't have to give VMS special treatment when looking for
features based on that macro.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1785)
Make Configure recognise -rpath and -R to support user added rpaths
for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the
Unix Makefile, which the users can use as follows:
./config [options] -Wl,-rpath,\$(LIBRPATH)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Before OpenSSL 1.1.0, binaries were installed in a non-standard
location by default, and runpath directories were therefore added in
those binaries, to make sure the executables would be able to find the
shared libraries they were linked with.
With OpenSSL 1.1.0 and on, binaries are installed in standard
directories by default, and the addition of runpath directories is
therefore not needed any more.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Note that it relies on a trick from Configure, where file names for
object files made from C++ source get '.cc' replaced with '_cc.o' to
recognise them. This is needed so the correct compiler is used when
linking binaries.
Reviewed-by: Rich Salz <rsalz@openssl.org>
A note: this will form object file names by changing '.cc' to
'_cc.o'. This will permit other configuration code to recognise these
object files were built for C++ rather than C.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This is an amendment to the september 8 commit titled "VMS: Don't
force symbol mixed case when building DSOs"
Reviewed-by: Rich Salz <rsalz@openssl.org>
This flag got moved after -xarch=v9 in 1.1.0 and had the unexpected
side effect of the compiler building for 32-bit v8plusa instead of v9.
GH#1521
CLA: none; trivial
Signed-off-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
This is generalised by having the following macros for stuff that won't
be installed:
NO_INST_LIB_CFLAGS, used instead of LIB_CFLAGS
NO_INST_DSO_CFLAGS, used instead of DSO_CFLAGS
NO_INST_BIN_CFLAGS, used instead of BIN_CFLAGS
They take values from corresponding target config fields if those are
defined, otherwise they take the respective values from LIB_CFLAGS,
DSO_CFLAGS and BIN_CFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Send a bit information to the build file template functions. For
src2obj(), the additional option 'product' holds the name of the final
file that the object file will go into. Additionally, the diverse
functions will get the option 'installed', with a value that evaluates
true if the final product is to be installed, otherwise false.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Improve interchangeability of aix*-gcc targets by linking shared
libraries with -static-libgcc, and address linking problems with
vendor compiler.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The background story is that util/shlib_wrap.sh was setting LD_PRELOAD
or similar platform dependent variables, just in case the shared
libraries were built with -rpath. Unfortunately, this doesn't work
too well with asan, msan or ubsan.
So, the solution is to forbid the combination of shared libraries,
-rpath and any of the sanity analyzers we can configure.
This changes util/shlib_wrap.sh so it only contains the code that sets
LD_PRELOAD when -rpath has been used when configuring.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In the case of using an independent makedepend, we had split that into
two separate recipes, one depending on the other. However, there are
cases where the makedepend recipe was always trying, but doesn't
update the time stamp of the .d file because there are no actual
changes, and thereby causing constant updates of the object files.
This change makes one recipe that takes care of both makedepend och
cc, thereby avoiding these extra updates.
Reviewed-by: Andy Polyakov <appro@openssl.org>
MIPS[32|64]R6 is binary and source incompatible with previous MIPS ISA
specifications. Fortunately it's still possible to resolve differences
in source code with standard pre-processor and switching to trap-free
version of addition and subtraction instructions.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Since vendor assembler can't assemble our modules with -KPIC flag,
it, assembly support, was not available as an option. But this
means lack of side-channel resistant code, which is incompatible
with security by todays standards.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Because some targets execute perl code that might die, we risk
incomplete lists. Make it so dying doesn't happen when we're listing
targets.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Most of the time, this isn't strictly needed. However, in the default
extern model (called relaxed refdef), symbols are treated as weak
common objects unless they are initialised. The librarian doesn't
include weak symbols in the (static) libraries, which renders them
invisible when linking a program with said those libraries, which is a
problem at times.
Using the strict refdef model is much more like standard C on all
other platforms, and thereby avoid the issues that come with the
relaxed refdef model.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The options RC4_CHUNK_LL, DES_PTR, and BF_PTR were removed by Rich
in commit 3e9e810f2e but were still
sticking around in a coupule configuration entries.
Since they're unused, remove them.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1390)
Experience shows that pod2html changes directory during its process
without properly adjusting the given source directory.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Instead, install the new one as openssl.cnf.dist (openssl.cnf-dist on
VMS), and only install it as openssl.cnf if that file doesn't already
exist.
Also, don't install with exec privileges on VMS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Windows never composes UTF-8 strings as result of user interaction
such as passing command-line argument. The only way to compose one
is programmatic conversion from WCHAR string, which in turn can be
picked up on command line.
[For reference, why not wmain, it's not an option on MinGW.]
Reviewed-by: Richard Levitte <levitte@openssl.org>
The way it was implemented before this change, the shared libraries
were installed twice. On a file system that supports file
generations, that's a waste. Slightly rearranging the install targets
solves the problem.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On non-Windows platforms, shared libraries are both development and
runtime files. We only installed them as development files, this
makes sure they get installed as runtime files as well.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This adds a new target 'build_programs' and makes 'build_apps' and
'build_tests' aliases for it, for backward compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org>
With a number of tools, especially those coming with Visual Studio,
some command options are separated from their argument with a space,
others with a space. Since we parametrise them, we can't know
beforehand which it will be, so we must allow the input and output
options to have either.
However, spaces at the end of nmake macro values are trimmed, so allow
spaces to exist by adding a reference to an undefined macro at the end.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is only done for the platforms where 'OPENSSL_USE_APPLINK' is defined.
Also, change the docs of OPENSSL_Applink to say where to find applink.c
in the installation directory.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll). MT (the Manifest Tool) is
the utility to use for this.
Reviewed-by: Rich Salz <rsalz@openssl.org>
With OpenSSL 1.1 and on, the engines are tightly tied to the shared
library they're to be used with. That makes them depend on the
pointer size as well as the shared library version, and this gets
reflected in the name of the directory they're installed in.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Some Unix variants require shared libraries to have the execute
permissions set, or they won't be loadable or executable when loaded.
Among others, cygwin has this requirement.
Reviewed-by: Matt Caswell <matt@openssl.org>
$openssldir and $enginesdir were mistakenly made unavailable to other
perl fragments. They are still needed in the definition of CFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
OpenSSL engines are tied to the OpenSSL shared library versions,
starting with OpenSSL 1.1. We therefore need to install them in
directories which have the shared library version in it's name, to
easily allow multiple OpenSSL versions to be installed at the same
time.
For VMS, the change is a bit more involved, primarly because the top
installation directory was already versioned, *as well as* some of the
files inside. That's a bit too much. Version numbering in files is
also a bit different on VMS. The engines for shared library version
1.1 will therefore end up in OSSL$INSTROOT:[ENGINES0101.'arch']
('arch' is the architecture we build for)
Reviewed-by: Rich Salz <rsalz@openssl.org>
OpenSSL engines are tied to the OpenSSL shared library versions,
starting with OpenSSL 1.1. We therefore need to install them in
directories which have the shared library version in it's name, to
easily allow multiple OpenSSL versions to be installed at the same
time.
For Unix, the default installation directory is changed from
$PREFIX/lib/engines to $PREFIX/lib/engines-${major}_${minor} (mingw)
or $PREFIX/lib/engines-${major}.${minor} (all but mingw)
($PREFIX is the directory given for the configuration option --prefix,
and ${major} and ${minor} are the major and minor shared library
version numbers)
Reviewed-by: Rich Salz <rsalz@openssl.org>
OpenSSL engines are tied to the OpenSSL shared library versions,
starting with OpenSSL 1.1. We therefore need to install them in
directories which have the shared library version in it's name, to
easily allow multiple OpenSSL versions to be installed at the same
time.
For windows, the default installation directory is changed from
$PREFIX/lib/engines to $PREFIX/lib/engines-${major}_${minor}
($PREFIX is the directory given for the configuration option --prefix,
and ${major} and ${minor} are the major and minor shared library
version numbers)
Reviewed-by: Rich Salz <rsalz@openssl.org>
When creating the library $lib.olb, make sure the extension is there.
Otherwise, a logical name with the same name as the file in question
will redirect the creation elsewhere.
Reviewed-by: Tim Hudson <tjh@openssl.org>
On VMS, it's customary to have a procedure to check that the software
was installed correctly and can run as advertised.
The procedure added here is fairly simple, it checks that all
libraries are in place, that the header crypto.h is in place, and that
the command 'openssl version -a' runs without trouble.
Reviewed-by: Rich Salz <rsalz@openssl.org>
- The install top is versioned by default. However, only the major
version should be used.
- the default areas for certs, private keys an config files have
changed, now all prefixed with 'OSSL$'. This gets reflected in
cryptlib.h.
- [.VMS]openssl_startup.com.in had some faults regarding creating
rooted concealed logical names.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This makes it possible for script writers to lock on to a specific
version if they need to. Note that only the major version number is
used.
Reviewed-by: Rich Salz <rsalz@openssl.org>
$prefix was removed as part of the DESTDIR work. However, it was
still used to create the ENGINESDIR_dev and ENGINESDIR_dir variables,
so a restoration is needed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
DESTDIR can't be used on Windows the same way as on Unix, the device
part of the installation paths get in the way.
To remedy this, have INSTALLTOP, OPENSSLDIR and ENGINESDIR get
different values depending on if $(DESTDIR) is empty or not, and use
$(INSTALLTOP), $(OPENSSLDIR) and $(ENGINESDIR) alone.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is just in case someone passed an inclusion path with the
configuration, and there are OpenSSL headers from another version
in there.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Since corresponding rule was removed from windows-makefile.tmpl out
of necessity, question popped if it's appropriate to harmonize even
unix-Makefile.tmpl. Note that as long as you work on single directory
'make lib<rary>.a' is effectively equivalent to 'make <dir/ectory>'
prior this modification.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Problem with Microsoft lib.exe is that it doesn't *update* modules
in .lib archive, but creates new one upon every invocation. As result
if a source file was updated and nmake was executed, a useless archive
with only one module was created. In other words one has to always
pass all .obj modules on command line, not only recently recompiled.
[This also creates dilemma for directory targets, e.g. crypto\aes,
that were added to simplify every-day life for developer. Since
whole idea behind those targets is to minimize the re-compile time
upon single file modification, the only sensible thing to do is to
omit intended library update.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
- User targets are now the same and generally do the same things
- configdata.pm depends on exactly the same files on all platforms
- VMS production of shared libraries is simplified
- VMS automatic dependency files get the extension .D rather than .MMS
Reviewed-by: Rich Salz <rsalz@openssl.org>
'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be
generated before anything else is built. It's likely that a number
of source files depend on these header files, this provides a simple
way to make sure they are always generated even it the dependency data
hasn't been added to the build file yet.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The directories for the final products were never registered, it was
plain luck that intermediary files were in the same place and
registered the directory anyway.
Also, scripts are generated directly from source (binaries go through
intermadiary object files), so we need to explicitely make sure to
avoid registering the source directory unless it's an in source
build.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Previous build scheme allowed building just the stuff in one
subdirectory, like this:
make -C crypto/aes
Because the unified only has a top-level Makefile, this is not
possible with it. This change adds a replacement where each directory
we have something to build in becomes a target in its own right,
allowing building something like this:
make crypto/aes
The exception is the directory test, because we already have such a
target.
Reviewed-by: Stephen Henson <steve@openssl.org>
This applies when building out-of-source.
RT#4486
NOTE: we can't do the same for Unix, as Unix make doesn't handle this
type of issue. Also, directory specs are much less likely to have
spaces on Unix...
Reviewed-by: Matt Caswell <matt@openssl.org>
Someone wants to configure like this:
PERL="/usr/bin/env perl" ./config
The end goal is to get that in the #! line of CA.pl and a few other
scripts. That works well already, but in the Makefile, there were a
few lines looking like this:
PERL=$(PERL) $(PERL) whatever.pl ...
Those need some quoting.
RT#4311
Reviewed-by: Matt Caswell <matt@openssl.org>
Add Configure generated header files to $unified_info{generate}. This
makes sure the build files will pick them up with the rest for the
GENERATED macro, and thereby make sure they get cleaned away by 'make
clean'
Reviewed-by: Rich Salz <rsalz@openssl.org>
Some setups use links inside .git directory and make clean should not
remove them to avoid breaking git meta-information.
Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>
CLA: none; trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1078)
DJGPP is a 3rd party configuration, we rely entirely on the OpenSSL to
help us fine tune and test. Therefore, it's moved to its own config.
Reviewed-by: Andy Polyakov <appro@openssl.org>
- some Perl versions are allergic to missing ';';
- don't stop if del fails;
- omit unused environment variable;
Reviewed-by: Stephen Henson <steve@openssl.org>
With Unixly Makefiles as well as with nmake, make variables are
transferred to the shell running the commands as envinronment
variables. This principle doesn't apply with MMS, so we must
explicitely define VERBOSE as commands when it's needed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If environment variables are not explanded early enough, expanded
strings are passed with single backslash to C compiler, e.g.
C:\Program Files, which effectively results in OpenSSL looking for
engines and certificates in C:Program Files.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Some non-Gnu compilers interpret -E -P combination differently.
some prioritize -E over -P, others -P over -E (in which case .i
file is generated and sometimes truncated because of redirection).
Reviewed-by: Richard Levitte <levitte@openssl.org>
When compiling all other C files, rely on the compiler to
automatically pick up the name translation information from the header
files __DECC_INCLUDE_{PRO,EPI}LOGUE.H.
Reviewed-by: Andy Polyakov <appro@openssl.org>
In the case of generating a file like this:
GENERATE[foo.S]=mkfoo.pl arg1 arg2
the 'mkfoo.pl' generator itself might need to include other files,
such as perl modules within our source tree. We can reuse already
existing syntax for it, like this:
INCLUDE[mkfoo.pl]=module/path
or:
DEPEND[mkfoo.pl]=modules/mymodule.pm
This change implements the support for such constructs, and for the
DEPEND statement, for any value that indicates a perl module (.pm
file), it will automatically infer an INCLUDE statement for its
directory, just like it does for C header files, so you won't have do
write this:
DEPEND[mkfoo.pl]=modules/mymodule.pm
INCLUDE[mkfoo.pl]=modules
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The Unix build was the last to retain the classic build scheme. The
new unified scheme has matured enough, even though some details may
need polishing.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This also restores the possibility to have ml used with VC-WIN32 with
no-asm, which was lost during the mk1mf -> unified transition.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Because we have a directory 'test', the target 'test' may be confusing
to make. However, if we make it depend on 'tests', which doesn't
exist, make should never fail to run the actions.
Reviewed-by: Andy Polyakov <appro@openssl.org>
To begin with, the default should have been the import library, not
the DLL itself. However, we don't know what directory it's installed
in either way, so we may as well demand the full path from the user
Reviewed-by: Matt Caswell <matt@openssl.org>
no-stdio does not work with the apps. Since the tests also need the apps
it doesn't support that either. Therefore we disable building of both.
no-autoalginit is not compatible with the apps because it requires explicit
loading of the algorithms, and the apps don't do that. Therefore we disable
building the apps for this option. Similarly the tests depend on the apps
so we also disable the tests. Finally the whole point about no-autoalginit
is to avoid excessive executable sizes when doing static linking. Therefore
we disable "shared" if this option is selected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The handling was Unix centric, already in Configure. Change that to
just collect the value and let the build file templates figure out
what to do with it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Instead of absolute hard coding of the libz library name, have it use
the macro LIBZ, which is set to defaults we know in case it's
undefined.
This allows our configuration to set something that's sane on current
or older platforms, and allows the user to override it by defining
LIBZ themselves.
Reviewed-by: Matt Caswell <matt@openssl.org>
The macros ZLIB and ZLIB_SHARED weren't appropriately defined,
deviating wrongly from how they worked in earlier OpenSSL versions.
So, restore it so that ZLIB is defined if configured "enable-zlib" and
so that ZLIB and ZLIB_SHARED are defined if configured
"enable-zlib-dynamic".
Additionally, correct the interpretation of the --with-zlib-lib value
on Windows and VMS, where it's used to indicate the actual zlib
zlib library file / logical name, as that can differ depending on zlib
version and packaging on those platforms.
Finally for Windows and VMS, we also define the macro LIBZ with that
file name / logical name when configured "zlib-dynamic", so the
compression unit can pick it up and use it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Since NDEBUG is defined unconditionally on command line for release
builds, we can omit *_DEBUG options in favour of effective "all-on"
in debug builds exercised though CI.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Without proper cleanup after DLL link failure second attempt to
run nmake would actually proceed and failure will be "shifted" to
run time. This is because libcrypto.lib import library is generated
even if DLL link fails.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We used to symlink generate_ssl_tests.pl to the build directory.
Now that the build scripts look for sources in both directories, this
is no longer necessary (see commit
fbd361eaf8).
Reviewed-by: Richard Levitte <levitte@openssl.org>
Currently, SSL tests are configured via command-line switches to
ssltest.c. This results in a lot of duplication between ssltest.c and
apps, and a complex setup. ssltest.c is also simply old and needs
maintenance.
Instead, we already have a way to configure SSL servers and clients, so
we leverage that. SSL tests can now be configured from a configuration
file. Test servers and clients are configured using the standard
ssl_conf module. Additional test settings are configured via a test
configuration.
Moreover, since the CONF language involves unnecessary boilerplate, the
test conf itself is generated from a shorter Perl syntax.
The generated testcase files are checked in to the repo to make
it easier to verify that the intended test cases are in fact run; and to
simplify debugging failures.
To demonstrate the approach, min/max protocol tests are converted to the
new format. This change also fixes MinProtocol and MaxProtocol
handling. It was previously requested that an SSL_CTX have both the
server and client flags set for these commands; this clearly can never work.
Guide to this PR:
- test/ssl_test.c - test framework
- test/ssl_test_ctx.* - test configuration structure
- test/handshake_helper.* - new SSL test handshaking code
- test/ssl-tests/ - test configurations
- test/generate_ssl_tests.pl - script for generating CONF-style test
configurations from perl inputs
Reviewed-by: Richard Levitte <levitte@openssl.org>
Previously, we updated the static libraries (libcrypto.a on Unix,
libcrypto.lib on Windows) with all the object files, regardless of if
they were rebuilt or not. With this change, we only update them with
the object files were rebuilt.
NOTE: this does not apply on VMS, as the expansion of $? may be too
large for a command line.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The logic to find out of there are any .d files newer than Makefile is
sound. Checking the result was less so.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reverts commit 087ca80ad8
Instead of battling the odd format of argv given to main() in default
P64 mode, tell the compiler to make it an array of 64-bit pointers
when compiling in P64 mode.
A note is added in NOTES.VMS regarding minimum DEC C version.
Reviewed-by: Andy Polyakov <appro@openssl.org>
- In Configure, register the perl interpreter used to run Configure,
so that's the one being used throughout instead of something else
that Configure happens to find. This is helpful for using a perl
version that's not necessarely first in $PATH:
/opt/perl/5.22.1/bin/perl ./Configure
- Make apps/tsget a generated file, just like apps/CA.pl, so the
perl interpreter registered by Configure becomes the hashbang path
instead of a hardcoded /usr/bin/perl
Reviewed-by: Andy Polyakov <appro@openssl.org>
There are rare cases when an object file will only be used when
building a shared library. To enable this, we introduce
SHARED_SOURCE:
SHARED_SOURCE[libfoo]=dllmain.c
Reviewed-by: Andy Polyakov <appro@openssl.org>
The warning MAYLOSEDATA3 is one you will always get when compiling
source that calculates the difference between two pointers with
/POINTER_SIZE=64.
The reason is quite simple, ptrdiff_t is always a 32-bit integer
regardless of pointer size, so the result of 'ptr1 - ptr2' can
potentially be larger than a 32-bit integer. The compiler simply
warns you of that possibility.
However, we only use pointer difference within objects and strings,
all of them well within 2^32 bytes in size, so that operation is
harmless with our source, and we can therefore safely turn off that
warning.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On Windows and Unix, the staging directory $(DESTDIR) can simply be
prepended to the installation directory. An attempt was made to do
something similar on VMS, but that ended up being a half measure
solution. Instead of that, simply use the staging directory as a
prefix under which [.OPENSSL-INSTALL] and [.OPENSSL-COMMON] will hold
the two directory trees that should end up in the directories
indicated by --prefix and --openssldir, and finish the installation
with appropriate instructions on what to do next.
Reviewed-by: Rich Salz <rsalz@openssl.org>
- on VMS, SYS$COMMON:[SSL] is already used as installation directory
by HP SSL, so we make our default for --openssldir
SYS$COMMON:[OPENSSL-COMMON] instead.
- Updated notes on default installation dirs fir Unix and Windows
Reviewed-by: Rich Salz <rsalz@openssl.org>
Sometimes, you might end up with a rather long compile line due to
excessively long /INCLUDE directories. Compensate for it by making
a temporary logical name with them and using said logical name as
/INCLUDE argument.
A note was added to NOTES.VMS regarding these limitations.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On VMS, we downcase option names, which means that config names are
downcased as well, so they need to be downcased in the target table to
be found.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In constructions such as 'for x in $(MAKEVAR); do ...', there's the
possibility that $(MAKEVAR) is en empty value. Some shells don't like
that, so introduce a dummy value that gets discarded:
for x in dummy $(MAKEVAR); do
if [ "$$x" = "dummy" ]; then continue; fi
Closes RT#4459
Reviewed-by: Rich Salz <rsalz@openssl.org>
utils/mkrc.pl was added a while ago as a better generator for the
Windows DLL resource file. Finalize the change by removing the
ms/version32.rc generator from Configure and adding resource file
support using mkrc.pl in Configurations/windows-makefile.pl
Reviewed-by: Andy Polyakov <appro@openssl.org>
One of the 'generate' targets depended on $(SRCDIR)/apps/progs.h,
which depended on... nothing. This meant it never got regenerated
once it existed, regardless of need. Of course, we could have it
depend on all the files checked to generate it, but they also depend
on progs.h, so we'd end up getting cricular dependencies, which makes
make unhappy.
Furthermore, and this applies for the other generated files, having
them as targets means that they may be regenerated on the fly in some
cases, and since they get written to the source tree, this isn't such
a good idea if that tree is read-only (which is a possible situation
in an out-of-tree build).
So, we move all the actions to the 'generate' targets themselves, thus
making sure they get regenerated in a controlled manner and regardless
of dependencies.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Some implementations of sed require a newline before an ending '}'.
The easier method is to replace that sed command with the
corresponding perl command.
Closes RT#4448
Reviewed-by: Rich Salz <rsalz@openssl.org>
Depending on what has been built so far, all .d files may not be
present and 'find' will exit with non-zero exit code. This isn't a
bother for us but may break make, so clear the exit code with an added
'exit 0'.
Closes RT#4444
Reviewed-by: Rich Salz <rsalz@openssl.org>
generatesrc() did already receive dependency information, but never
used it, and never really needed to... until now.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Instead of relying on the '-nt' test operator, which doesn't exist
everywhere, use find's '-newer' to find out if any of the known .d
files is newer than Makefile.
Closes RT#4444
Reviewed-by: Andy Polyakov <appro@openssl.org>
On Windows, we set INSTALLTOP to default as follows:
VC-WIN32:
PREFIX: %ProgramFiles(x86)%\OpenSSL
OPENSSLDIR: %CommonProgramFiles(x86)%\SSL
VC-WIN64*:
PREFIX: %ProgramW6432%\OpenSSL
OPENSSLDIR: %CommonProgramW6432%\SSL
Should those environment variables be missing, the following is used
as fallback:
PREFIX: %ProgramFiles%\OpenSSL
OPENSSLDIR: %CommonProgramFiles%\SSL
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is a living document, everyone is encouraged to add to it.
Implementation details as well as broader implementation philosophy
has a place here.
I'm starting with documentation of the how conditions in build.info
files are treated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In most builds, we can assume that engines live in the build tree
subdirectory "engines". This was hard coded into the tests that use
the engine ossltest.
However, that hard coding is tedious, it would need to be done in
every test recipe, and it's an incorrect assumption in some cases.
This change has us play it safe and let the build files tell the
testing framework where the engines are.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
util/mkdef.pl assumes it knows what the resulting library name will
be. Really, it shouldn't, but changing it will break classic native
Windows builds, so we leave it for now and change the LIBRARY line
externally when needed instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
Normally we always refer to source files relative to $SRCDIR in Makefiles.
However the reference to unix-Makefile.tmpl was using a fully expanded
absolute path. This can cause problems for Mingw.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
In unix-Makefile.tmpl, this construction has been used a few times
if ! something; then ...
It seems, though, that some shells do not understand !, so these need
to be changed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When passing down values to Makefile.shared, do so with single quotes
as much as possible to avoid having the shell create a mess of quotes.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared". The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.
To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS. That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.
Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: Rich Salz <rsalz@openssl.org>
It turns out that different sed implementations treat -i differently
to cause issues. make it simpler by avoiding it entirely and give
perl the trust to be consistent enough.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If pre-processor failed, an empty .s file could be left behind,
which could get successfully compiled if one simply re-ran make
and cause linking failures. Not anymore. Remove even intermediate .S
in case of pre-processor failure.
Reviewed-by: Richard Levitte <levitte@openssl.org>
One of them didn't clean away .d.tmp files properly.
The other would overwrite the .d files unconditionally, thereby
causing a possibly unnecessary dependency rebuild, which touches the
date of Makefile, which causes a possibly unnecessary rebuild of
buildinf.h and everything that depends on that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The source file generators sometimes use $(CC) to post-process
generated source, and getting the inclusion directories may be
necessary at times, so we pass them down.
RT#4406
Reviewed-by: Rich Salz <rsalz@openssl.org>
The reason for this is that the static libraries and the DLL import
libraries are named the same on Windows. When configured "shared",
the static libraries are unused anyway.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This introduces the settings loutflag and aroutflag, because different
Windows tools that do the same thing have different ways to specify
the output file.
The Borland C++ config is commented away for the monent, perhaps
permanently.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This change is a bit more complex, as it involves several recipe
variants.
Also, remove the $(CROSS_COMPILE) prefix for the makedepend program.
When we use the program "makedepend", this doesn't serve anything,
and when we use the compiler, this value isn't even used.
Reviewed-by: Rich Salz <rsalz@openssl.org>
VMS doesn't have "makedepend" anyway, so this is just a matter of using
the right qualifiers when 'makedepend' is enabled.
Reviewed-by: Rich Salz <rsalz@openssl.org>
For assembler, we want the final target to be foo.s (lowercase s).
However, the build.info may have lines like this (note upper case S):
GENERATE[foo.S]=foo.pl
This indicates that foo.s (lowercase s) is still to be produced, but
that producing it will take an extra step via $(CC) -E. Therefore,
the following variants (simplified for display) can be generated:
GENERATE[foo.S]=foo.pl => foo.s: foo.pl
$(PERL) $foo.pl $@.S; \
$(CC) $(CFLAGS) -E -P $@.S > $@ && \
rm -f $@.S
GENERATE[foo.s]=foo.pl => foo.s: foo.pl
$(PERL) $foo.pl $@
GENERATE[foo.S]=foo.m4 => foo.s: foo.m4
m4 -B 8192 $foo.m4 > $@.S; \
$(CC) $(CFLAGS) -E -P $@.S > $@ && \
rm -f $@.S
GENERATE[foo.s]=foo.m4 => foo.s: foo.m4
m4 -B 8192 $foo.m4 > $@
Reviewed-by: Andy Polyakov <appro@openssl.org>
Make all scripts produce .S, make interpretation of $(CFLAGS)
pre-processor's responsibility, start accepting $(PERLASM_SCHEME).
[$(PERLASM_SCHEME) is redundant in this case, because there are
no deviataions between Solaris and Linux assemblers. This is
purely to unify .pl->.S handling across all targets.]
Reviewed-by: Richard Levitte <levitte@openssl.org>
For config targets such as 'dist', which doesn't have a BASE template,
we still need to have a default build scheme.
Additionally, the unified Makefile template's target 'tar' wasn't
quite as flexible as the unixmake one.
Finally, .travis-create-release.sh can be somewhat simplified now that
it builds with the unified build scheme.
Reviewed-by: Matt Caswell <matt@openssl.org>
Should it be needed because the recipes within a RAW section might
clash with those generated by Configure, it's possible to tell it
not to generate them with the use of OVERRIDES, for example:
SOURCE[libfoo]=foo.c bar.c
OVERRIDES=bar.o
BEGINRAW[Makefile(unix)]
bar.o: bar.c
$(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
ENDRAW[Makefile(unix)]
Reviewed-by: Rich Salz <rsalz@openssl.org>
In some cases, one might want to generate some source files from
others, that's done as follows:
GENERATE[foo.s]=asm/something.pl $(CFLAGS)
GENERATE[bar.s]=asm/bar.S
The value of each GENERATE line is a command line or part of it.
Configure places no rules on the command line, except the the first
item muct be the generator file. It is, however, entirely up to the
build file template to define exactly how those command lines should
be handled, how the output is captured and so on.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them. Our solution was to use -fno-common when compiling
C source.
Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition. -fno-common doesn't help in this case.
However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.
The common conclusion is, either use -fno-common or ranlib -c on
Darwin. Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
We copied $target{cflags}, $target{defines} and a few more to %config,
just to add to the entries. Avoid doing so, and let the build templates
deal with combining the two.
There are a few cases where we still fiddle with %target, but that's
acceptable.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
Instead, make the build type ("debug" or "release") available through
$config{build_type} and let the configs themselves figure out what the
usual settings (such as "cflags", "lflags" and so on) should be
accordingly.
The benefit with this is that we can now have debug and release
variants of any setting, not just those Configure supports, and may
also involve other factors (the MSVC flags /MD[d] and /MT[d] involve
both build type and whether threading is enabled or not)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Configure had the Unix centric addition of -lz when linking with zlib
is enabled, which doesn't work on other platforms. Therefore, we move
it to the BASE_unix config template and add corresponding ones in the
other BASE_* config templates. The Windows one is probably incomplete,
but that doesn't matter for the moment, as mk1mf does it's own thing
anyway.
This required making the %withargs table global, so perl snippets in
the configs can use it.
Reviewed-by: Andy Polyakov <appro@openssl.org>
These BASE templates are intended to hold values that are common for
all configuration variants for whole families of configurations.
So far, three "families" are identified: Unix, Windows and VMS, mostly
characterised by the build system they currently use.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This has no real meaning, except it gives Configure a hint that VC
targets are indeed capable of producing shared objects.
Reviewed-by: Matt Caswell <matt@openssl.org>
There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones. The best way to
solve this is to separate the two.
Reviewed-by: Andy Polyakov <appro@openssl.org>
When building with GNU C, clang or VMS C, it's more efficient to
generate dependency file and object file in one call rather than two.
Have the dependency output in a temporary file and compare it with the
previous one if available to see if replacement is waranted, thereby
avoiding unnecessary reconstruction of Makefile / descrip.mms.
Github issue #750
Reviewed-by: Rich Salz <rsalz@openssl.org>
I read the PROBLEMS, and they're outdated; nothing I'd put in the
online FAQ, for example. Test-builds work without using these files.
Had to remove the rehash.time stuff from Makefile.in
Reviewed-by: Richard Levitte <levitte@openssl.org>
They now default to " " as separator, but that can be overridden by
having a hash with parameters as last argument. The only currently
recognised parameter is `separator'.
The special separator `undef' will force the result to become a list
rather than a concatenated string.
Reviewed-by: Andy Polyakov <appro@openssl.org>
If the local system doesn't have GNU C or clang, and not even
makedepend, the build will stop because the call of 'makedepend'
fails. This changes so the build won't stop because of such failure.
The result will be empty .d files, and that's ok.
Reviewed-by: Rich Salz <rsalz@openssl.org>
These flags are limitting needlessly, are often patched by packagers,
and should be specified on the configuration command line by anyone
who desires for it to be specific rather than forced by us.
This work was already done with mingw when those configs were worked
on, now it gets applied to the remaining configs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
GNU make will re-exec if (it thinks that) the Makefile has changed.
Just having the target Makefile seems to make it think it has, so we
end up in a look where GNU make re-execs for ever.
The fix is easy, just remove the Makefile target and have the depend
target run the recipe on its own instead of depending on Makefile.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This takes us away from the idea that we know exactly how our static
libraries are going to get used. Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.
On the other hand, we also have greater control of when the shared
library cflags. They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.
With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: Rich Salz <rsalz@openssl.org>
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Better libclean that removes the exact files that have been built,
nothing more and nothing less.
Corrected typo
A couple of editorial changes.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Instead of having the installation recipe rely on special knowledge,
feed it with information, including what shared library files belong
together. For Cygwin and Mingw, that's the .dll and its import
library .dll.a. For Unixen, it's the shared library file name with SO
version and the one without.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Originally, the Makefile.shared targets described what they used as
input for a shared object, be it a shared library or a DSO. It turned
out, however, that the link_o targets were used exclusively for
engines and the link_a targets were for libcrypto and libssl.
This rename fest turns and indication on the kind of input the targets
get to the intention with using them.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Then it can pass around the information where it belongs. The
Makefile templates pick it up along with other target data, the
DSO module gets to pick up the information through
crypto/include/internal/dso_conf.h
Reviewed-by: Andy Polyakov <appro@openssl.org>
- install_sw had a display of text that belongs under the install target
- previous layout installed architecture dependent files in
dev:['prefix'.'arch'.LIB], dev:['prefix'.'arch'.EXE] and
dev:['prefix'.'arch'.ENGINES]. Changed to dev:['prefix'.LIB.'arch'],
dev:['prefix'.EXE.'arch'] and dev:['prefix'.ENGINES.'arch'] instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is done with a simple file name comparison. We could think of
something more elegant in the future.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Adding uplink and applink to some builds was done by "magic", the
configuration for "mingw" only had a macro definition, the Configure
would react to its presence by adding the uplink source files to
cpuid_asm_src, and crypto/build.info inherited dance to get it
compiled, and Makefile.shared made sure applink.o would be
appropriately linked in. That was a lot under the hood.
To replace this, we create a few template configurations in
Configurations/00-base-templates.conf, inherit one of them in the
"mingw" configuration, the rest is just about refering to the
$target{apps_aux_src} / $target{apps_obj} in the right places.
Reviewed-by: Andy Polyakov <appro@openssl.org>
VMS DIFF tries to calculate all the differences, which is slower than
just reading the files and stopping at the first difference. The
latter doesn't exist as a command, so the problem is solved with perl
and File::Compare (has been in core perl since very early version 5).
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
DCL may be in extended parsing style, which makes it less case
insensitive, so when removing a string from another, make sure to get
casing correctly.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
This isn't the fully featured combination of compiler generated
dependency files and Makefile include directives, but a cheaper
variant of the same.
The dependency files are generated automatically, but then we have the
usual "depend" target. However, we depend on it in the bigger phony
targets that are the most likely to be used. That make this feature
automatic enough.
A side effect is that we can't use the build file's timestamp to check
if reconfiguring might be in order. In its place, we use a flag file
that depends on Configure and the build file template and depend on it
in spots where it makes sense to check for the need to reconfigure.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When cross compiling, we may end up with someting like apps/openssl.exe
and a number of test/*.exe. However, util/shlib_wrap.sh doesn't know
what the executable extension should be, if any, so we need to make
sure it has access to that information when testing, since
OpenSSL::Test uses that script to execute all programs.
Reviewed-by: Rich Salz <rsalz@openssl.org>
All those flags existed because we had all the dependencies versioned
in the repository, and wanted to have it be consistent, no matter what
the local configuration was. Now that the dependencies are gone from
the versioned Makefile.ins, it makes much more sense to use the exact
same flags as when compiling the object files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
.d (.MMS in the VMS world) files with just dependencies are built from
exactly the same conditions as the object files. Therefore, the rules
for them can be built at the same time as the rules for the
corresponding object files.
This removes the requirement for a src2dep function in the build file
templates, and for common.tmpl to call it. In the end, the existence
of depend files is entirely up to the build file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
That variable isn't for us, it's for any user, distributor or package
builder that wants one after the section number. "ssl" seems to be
popular...
Reviewed-by: Matt Caswell <matt@openssl.org>
The installation of man files and html files alike didn't properly
check that file names with different casing could be the same on
case-insensitive file systems. This change fixes that.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There was a catch 22, where 'make depend' directly after configuring
in an otherwise pristine build tree would fail because buildinf.h
didn't exist yet.
This change has the depend building targets depend on the same other
targets as the object file building targets, so the generation of
buildinf.h and similar files would kick in during 'make depend'.
Reviewed-by: Rich Salz <rsalz@openssl.org>
INSTALL_PREFIX is a confusing name, as there's also --prefix.
Instead, tag along with the rest of the open source world and adopt
the Makefile variable DESTDIR to designate the desired staging
directory.
The Configure option --install_prefix is removed, the only way to
designate a staging directory is with the Makefile variable (this is
also implemented for VMS' descrip.mms et al).
Reviewed-by: Rich Salz <rsalz@openssl.org>
apps/progs.pl counted on the caller to provide the exact command
files. The unified build doesn't have that knowledge, and the easier
and more flexible thing to do is to feed it all the apps/*.c files and
let it figure out the command names by looking inside (looking for
/int ([a-z0-9][a-z0-9_]*)_main\(int argc,/).
Also, add it to the generate command, since it's a versioned file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On Windows POSIX layers, two files are produced for a shared library,
there's {shlibname}.dll and there's the import library {libname}.dll.a
On some/most Unix platforms, a {shlibname}.{sover}.so and a symlink
{shlibname}.so are produced.
For each of them, unix-Makefile.tmpl was entirely consistent on which
to have as a target when building a shared library or which to use as
dependency.
This change clears this up and makes it consistent, we use the
simplest form possible, {lib}.dll.a on Windows POSIX layers and
{shlibname}.so on Unix platforms. No exception.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Because the command line definitions of OPENSSLDIR and ENGINESDIR
contain quotes, we need a variant of CFLAG where backslashes and
quotes are escaped when we produce buildinf.h
Reviewed-by: Rich Salz <rsalz@openssl.org>