- 09 3月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5534)
-
- 07 3月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5545)
-
- 28 2月, 2018 1 次提交
-
-
由 Rich Salz 提交于
And only generate one output "file" at a time for objects.pl Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5432)
-
- 26 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5446)
-
- 23 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
The reason for this is that some of the C flags affect built in macros that we may depend on. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5436)
-
- 22 2月, 2018 3 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5247)
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5247)
-
由 Richard Levitte 提交于
It was inconsistent to see this specific command have '$(CROSS_COMPILE)' in its value when no other command did. Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5247)
-
- 15 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5357)
-
- 14 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NPaul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/5356)
-
- 09 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5296)
-
- 08 2月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5275)
-
- 30 1月, 2018 2 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5197)
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5185)
-
- 28 1月, 2018 3 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5181)
-
由 Richard Levitte 提交于
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: NTim Hudson <tjh@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5177)
-
由 Richard Levitte 提交于
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: NTim Hudson <tjh@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5177)
-
- 23 1月, 2018 2 次提交
-
-
由 Richard Levitte 提交于
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: NBernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/5134)
-
由 Richard Levitte 提交于
Fixes #5143 Reviewed-by: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5144)
-
- 08 1月, 2018 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5033)
-
- 18 12月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
It is a hack, but it existed in the recently removed Makefile.shared, and its use is documented in fuzz/README.md, so we cannot drop it now. Fixes https://github.com/google/oss-fuzz/issues/1037Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4947)
-
- 16 12月, 2017 1 次提交
-
-
由 Bernd Edlinger 提交于
Ignore libssl.map/libcrypto.map instead of ssl.map/crypto.map Reviewed-by: NRichard Levitte <levitte@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4932)
-
- 13 12月, 2017 2 次提交
-
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4840)
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4840)
-
- 01 12月, 2017 1 次提交
-
-
由 Viktor Dukhovni 提交于
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: NRichard Levitte <levitte@openssl.org>
-
- 09 11月, 2017 1 次提交
-
-
由 Andy Polyakov 提交于
HP-UX make doesn't recognize $< in explict target rules, only in inference ones such as .c.o. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4697)
-
- 01 11月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> Reviewed-by: NKurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/4637)
-
- 09 10月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4507)
-
- 25 8月, 2017 1 次提交
-
-
由 Meena Vyas 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org> Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4249)
-
- 18 8月, 2017 3 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4179)
-
由 Richard Levitte 提交于
We changed directory to the wrong directory. This change also separates the preparation phase from the tarball building phase. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4179)
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4179)
-
- 17 8月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
submodules are directories that we don't want in our tarballs, so avoid them. Reviewed-by: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4178)
-
- 27 7月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
$(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: NAndy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3964)
-
- 24 7月, 2017 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3983)
-
- 30 6月, 2017 1 次提交
-
-
由 Rich Salz 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3801)
-
- 16 6月, 2017 2 次提交
-
-
由 Richard Levitte 提交于
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: NTim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3695)
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3688)
-
- 09 6月, 2017 1 次提交
-
-
由 Rich Salz 提交于
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: NMatt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3624)
-
- 08 6月, 2017 1 次提交
-
-
由 Rich Salz 提交于
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: NRichard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3392)
-