From: Laszlo Ersek <lersek@redhat.com>
To: "Gao, Liming" <liming.gao@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [PATCH] BaseTools/VfrCompile: honor EXTRA_LDFLAGS
Date: Wed, 22 Aug 2018 18:40:51 +0200 [thread overview]
Message-ID: <9668ad8d-c267-cebc-6f98-26e24036dc4c@redhat.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E2E7773@SHSMSX104.ccr.corp.intel.com>
On 08/22/18 18:34, Gao, Liming wrote:
> Reviewed-by: Liming Gao <liming.gao@intel.com>
Thanks!
> And, push at aa4e0df1f0c7ffdff07d7e382c9da89cbe207cdb
That's very kind of you! Thanks! :)
Laszlo
> Thanks
> Liming
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Thursday, August 16, 2018 7:38 PM
>> To: edk2-devel-01 <edk2-devel@lists.01.org>
>> Cc: Gao, Liming <liming.gao@intel.com>; Zhu, Yonghong <yonghong.zhu@intel.com>
>> Subject: [PATCH] BaseTools/VfrCompile: honor EXTRA_LDFLAGS
>>
>> In commit 81502cee20ac ("BaseTools/Source/C: take EXTRA_LDFLAGS from the
>> caller", 2018-08-16), I missed that "VfrCompile/GNUmakefile" does not use
>> BUILD_LFLAGS in the APPLICATION linking rule, unlike "app.makefile" does.
>> Instead, "VfrCompile/GNUmakefile" uses the (undefined) LFLAGS macro.
>> Therefore commit 81502cee20ac did not cover the linking step of
>> VfrCompile.
>>
>> Thankfully, the structure of the linking rules is the same, between
>> "app.makefile" and "VfrCompile/GNUmakefile". Rename the undefined LFLAGS
>> macro in "VfrCompile/GNUmakefile" to VFR_LFLAGS (for consistency with
>> VFR_CXXFLAGS), and set it to EXTRA_LDFLAGS.
>>
>> As a result, we have:
>>
>> | compilation | linking
>> -----------+--------------------------------+----------------------
>> VfrCompile | VFR_CXXFLAGS = | VFR_LFLAGS =
>> | BUILD_OPTFLAGS = | EXTRA_LDFLAGS
>> | '-O2' + EXTRA_OPTFLAGS |
>> -----------+--------------------------------+----------------------
>> other apps | BUILD_CFLAGS/BUILD_CXXFLAGS = | BUILD_LFLAGS =
>> | [...] + BUILD_OPTFLAGS = | [...] + EXTRA_LDFLAGS
>> | [...] + '-O2' + EXTRA_OPTFLAGS |
>>
>> This table shows
>> - that the VfrCompile compilation and linking flags are always a subset of
>> the corresponding flags used by the other apps,
>> - and that the EXTRA flags are always at the end.
>>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1540244
>> Fixes: 81502cee20ac4046f08bb4aec754c7091c8808dc
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>> Repo: https://github.com/lersek/edk2.git
>> Branch: extra_flags_rhbz1540244_round2
>>
>> BaseTools/Source/C/VfrCompile/GNUmakefile | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile
>> index bbe562cbc54f..9273589ff805 100644
>> --- a/BaseTools/Source/C/VfrCompile/GNUmakefile
>> +++ b/BaseTools/Source/C/VfrCompile/GNUmakefile
>> @@ -28,6 +28,9 @@ VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(BUILD_CPPFLAGS)
>> # keep BUILD_OPTFLAGS last
>> VFR_CXXFLAGS = $(BUILD_OPTFLAGS)
>>
>> +# keep EXTRA_LDFLAGS last
>> +VFR_LFLAGS = $(EXTRA_LDFLAGS)
>> +
>> LINKER = $(BUILD_CXX)
>>
>> EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h
>> @@ -42,7 +45,7 @@ APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
>> all: $(MAKEROOT)/bin $(APPLICATION)
>>
>> $(APPLICATION): $(OBJECTS)
>> - $(LINKER) -o $(APPLICATION) $(LFLAGS) $(OBJECTS) -L$(MAKEROOT)/libs $(LIBS)
>> + $(LINKER) -o $(APPLICATION) $(VFR_LFLAGS) $(OBJECTS) -L$(MAKEROOT)/libs $(LIBS)
>>
>> VfrCompiler.o: ../Include/Common/BuildVersion.h
>>
>> --
>> 2.14.1.3.gb7cf6e02401b
>
prev parent reply other threads:[~2018-08-22 16:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 2:38 [PATCH] BaseTools/VfrCompile: honor EXTRA_LDFLAGS Laszlo Ersek
2018-08-22 8:24 ` Laszlo Ersek
2018-08-22 16:34 ` Gao, Liming
2018-08-22 16:40 ` Laszlo Ersek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9668ad8d-c267-cebc-6f98-26e24036dc4c@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox