- Mar 10, 2018
-
-
Andy Polyakov authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5574)
-
Andy Polyakov authored
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 authored
A missing parenthesis here, a missing comma there... Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5579)
-
- Mar 09, 2018
-
-
Andy Polyakov authored
This includes even ARM targets. Reviewed-by:
-
Andy Polyakov authored
$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: -
Andy Polyakov authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5560)
-
Richard Levitte authored
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:
-
- Mar 08, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
Michael Richardson authored
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:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
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:
-
Richard Levitte authored
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:
-
- Mar 07, 2018
-
-
Richard Levitte authored
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:
-
- Mar 06, 2018
-
-
Andy Polyakov authored
-fno-common was removed for all Darwin targets in 0c873419 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:
-
- Mar 03, 2018
-
-
Richard Levitte authored
Rely on the build.info constructor to do the right thing. Fixes #5500 Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5501)
-
- Feb 27, 2018
-
-
Rich Salz authored
And only generate one output "file" at a time for objects.pl Reviewed-by:
-
- Feb 26, 2018
-
-
Richard Levitte authored
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:
-
- Feb 22, 2018
-
-
Richard Levitte authored
The reason for this is that some of the C flags affect built in macros that we may depend on. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
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:
-
Richard Levitte authored
It was inconsistent to see this specific command have '$(CROSS_COMPILE)' in its value when no other command did. Reviewed-by:
-
- Feb 21, 2018
-
-
Andy Polyakov authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5408)
-
- Feb 15, 2018
-
-
Richard Levitte authored
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:
-
- Feb 14, 2018
-
-
Richard Levitte authored
Avoid using crypto/modes/ghash-ia64.s, as it uses features that are explicitely prohibited on VMS. Reviewed-by:
-
Richard Levitte authored
This does require the use of a port of 'ias' for VMS. Reviewed-by:
-
Richard Levitte authored
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:
-
Richard Levitte authored
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: -
Richard Levitte authored
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:
-
- Feb 13, 2018
-
-
Matt Caswell authored
Reviewed-by:
-
- Feb 09, 2018
-
-
Richard Levitte authored
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:
-
Richard Levitte authored
Configurations/descrip.mms.tmpl didn't treat the includes config attribute very well. In fact, it didn't treat it at all! Reviewed-by:
-
- Feb 08, 2018
-
-
Richard Levitte authored
The slash should be there according to Microsoft documentation, see https://msdn.microsoft.com/en-us/library/7cafx990.aspx Fixes #5277 Reviewed-by:
-
- Feb 07, 2018
-
-
Richard Levitte authored
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:
-
- Feb 01, 2018
-
-
Richard Levitte authored
So as not to be mixed up with a device specification... Reviewed-by:
-
- Jan 31, 2018
-
-
Richard Levitte authored
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:
-
- Jan 30, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
