Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: NHJ <huangjun42@huawei.com>

Description:openssl 1.1.1d used bu libhapverify
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:Yes, it is
PrivateCode(Yes/No):No

Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b
Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com>
Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com>
Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>

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)

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)

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: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4840)

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: NAndy Polyakov <appro@openssl.org>