#
29d82bd9 |
| 25-Sep-2022 |
J.W. Jagersma |
djgpp: Inherit config from BASE_unix Build failed on djgpp due to missing config vars 'AR' and 'ARFLAGS'. Additionally, '-lz' was not added to 'lflags' when zlib support was enabled.
djgpp: Inherit config from BASE_unix Build failed on djgpp due to missing config vars 'AR' and 'ARFLAGS'. Additionally, '-lz' was not added to 'lflags' when zlib support was enabled. Inheriting configuration variables from BASE_unix solves both these issues. CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19274)
show more ...
|
Revision tags: openssl-3.0.0-alpha17, openssl-3.0.0-alpha16, openssl-3.0.0-alpha15, openssl-3.0.0-alpha14, OpenSSL_1_1_1k, openssl-3.0.0-alpha13, openssl-3.0.0-alpha12, OpenSSL_1_1_1j, openssl-3.0.0-alpha11, openssl-3.0.0-alpha10, OpenSSL_1_1_1i, openssl-3.0.0-alpha9, openssl-3.0.0-alpha8, openssl-3.0.0-alpha7, OpenSSL_1_1_1h, openssl-3.0.0-alpha6, openssl-3.0.0-alpha5, openssl-3.0.0-alpha4, openssl-3.0.0-alpha3, openssl-3.0.0-alpha2, openssl-3.0.0-alpha1, OpenSSL_1_1_1g, OpenSSL_1_1_1f, OpenSSL_1_1_1e, OpenSSL_1_0_2u, OpenSSL_1_0_2t, OpenSSL_1_1_0l, OpenSSL_1_1_1d |
|
#
30478c97 |
| 16-Jun-2019 |
Richard Levitte |
Configure: final cleanup of asm related things Remove the *_asm templates in Configurations/00-base-templates.conf, all attempts to inherit them, and the asm() perl function. [e
Configure: final cleanup of asm related things Remove the *_asm templates in Configurations/00-base-templates.conf, all attempts to inherit them, and the asm() perl function. [extended tests] Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
show more ...
|
#
e6f98ae4 |
| 16-Jun-2019 |
Richard Levitte |
Configure: add mechanism to specify asm target architecture As preparation for moving asm file specs to build.info files, we must make sure there is still some base information to help s
Configure: add mechanism to specify asm target architecture As preparation for moving asm file specs to build.info files, we must make sure there is still some base information to help select the correct files. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
show more ...
|
Revision tags: OpenSSL_1_1_1c, OpenSSL_1_1_0k, OpenSSL_1_0_2s, OpenSSL_1_0_2r, OpenSSL_1_1_1b, OpenSSL_1_0_2q, OpenSSL_1_1_0j, OpenSSL_1_1_1a, OpenSSL_1_1_1, OpenSSL_1_1_1-pre9, OpenSSL_1_0_2p, OpenSSL_1_1_0i, OpenSSL_1_1_1-pre8, OpenSSL_1_1_1-pre7, OpenSSL_1_1_1-pre6, OpenSSL_1_1_1-pre5, OpenSSL_1_1_1-pre4, OpenSSL_1_0_2o, OpenSSL_1_1_0h, OpenSSL_1_1_1-pre3 |
|
#
abe256e7 |
| 06-Mar-2018 |
Richard Levitte |
Make "make variables" config attributes for overridable flags With the support of "make variables" comes the possibility for the user to override them. However, we need to make a differ
Make "make variables" config attributes for overridable flags 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)
show more ...
|
Revision tags: OpenSSL_1_1_1-pre2, OpenSSL_1_1_1-pre1 |
|
#
47eeaf45 |
| 08-Jan-2018 |
Richard Levitte |
Separate general linking flags from extra libraries So far, we've placed all extra library related flags together, ending up in the make variable EX_LIBS. This turns out to be problemat
Separate general linking flags from extra libraries 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)
show more ...
|
Revision tags: OpenSSL_1_0_2n |
|
#
3b6c4b07 |
| 01-Dec-2017 |
Richard Levitte |
Configure: Add read_eval_file, a general purpose perl file reader/evaluator It will return the last expression from the input file. We also use this in read_config, which slightly c
Configure: Add read_eval_file, a general purpose perl file reader/evaluator 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)
show more ...
|
Revision tags: OpenSSL_1_0_2m, OpenSSL_1_1_0g, OpenSSL_1_0_2l, OpenSSL_1_1_0f, OpenSSL-fips-2_0_16, OpenSSL_1_1_0e, OpenSSL_1_0_2k, OpenSSL_1_1_0d, OpenSSL-fips-2_0_15, OpenSSL-fips-2_0_14, OpenSSL_1_1_0c, OpenSSL_1_0_2j, OpenSSL_1_1_0b, OpenSSL_1_0_1u, OpenSSL_1_0_2i, OpenSSL_1_1_0a, OpenSSL_1_1_0, OpenSSL_1_1_0-pre6, OpenSSL-fips-2_0_13 |
|
#
ae69c7d3 |
| 11-May-2016 |
Richard Levitte |
Move the DJGPP target to its own config. 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.
Move the DJGPP target to its own config. 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>
show more ...
|