Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

2018-02-28, Masahiro Yamada:
[snip]
> So, my idea is to rename existing
> 
>  HOSTCFLAGS ->  KBUILD_HOSTCFLAGS
>  HOSTCXXFLAGS   ->  KBUILD_HOSTCXXFLAGS
>  HOSTLDFLAGS->  KBUILD_HOSTLDFLAGS
>  HOST_LOADLIBES ->  KBUILD_HOSTLDLIBS
> 
> 
> ("LOADLIBES" is too long, so rename it to "LDLIBS")
> 
> 
> Then, re-add no-prefix ones as user interface.

Hi Masahiro,

Ok, I'll add the rename patch in a v3 of my series.

-- 
Robin

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

2018-02-28, Masahiro Yamada:
[snip]
> So, my idea is to rename existing
> 
>  HOSTCFLAGS ->  KBUILD_HOSTCFLAGS
>  HOSTCXXFLAGS   ->  KBUILD_HOSTCXXFLAGS
>  HOSTLDFLAGS->  KBUILD_HOSTLDFLAGS
>  HOST_LOADLIBES ->  KBUILD_HOSTLDLIBS
> 
> 
> ("LOADLIBES" is too long, so rename it to "LDLIBS")
> 
> 
> Then, re-add no-prefix ones as user interface.

Hi Masahiro,

Ok, I'll add the rename patch in a v3 of my series.

-- 
Robin

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Masahiro Yamada]

2018-02-28 2:45 GMT+09:00 Josh Poimboeuf :
> On Mon, Feb 26, 2018 at 07:41:45PM +0100, Robin Jarry wrote:
>> This patchset allows to build host programs that depend on external libs
>> installed in non standard locations (i.e. not in /usr/include, /usr/lib,
>> etc.).  For now, the only way is to force HOSTCC to include both the
>> path to the host compiler and the build flags.
>>
>> I have encountered this issue when building linux into the buildroot
>> framework. host-* versions of libs may be compiled and installed in a
>> host staging dir removing the need to install them on the build system.
>>
>> I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
>> are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
>> HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
>> Documentation/kbuild/makefiles.txt).  And I didn't want to have even
>> longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
>> happily make a v3.
>
> In Documentation/kbuild/kbuild.txt, we have the following environment
> variables:
>
>   KCFLAGS
>   --
>   Additional options to the C compiler (for built-in and modules).
>
>   CFLAGS_KERNEL
>   --
>   Additional options for $(CC) when used to compile
>   code that is compiled as built-in.
>
>   CFLAGS_MODULE
>   --
>   Additional module specific options to use for $(CC).
>
>   LDFLAGS_MODULE
>   --
>   Additional options used for $(LD) when linking modules.
>
>   LDFLAGS_vmlinux
>   --
>   Additional options passed to final link of vmlinux.
>
> So instead of
>
>   HOST_CFLAGS
>   HOST_LDFLAGS
>
> maybe it would be more consistent to call them
>
>   CFLAGS_HOST
>   LDFLAGS_HOST
>
> ?
>
> Also, the new environment variables should be documented in the above
> file.
>
> --
> Josh



A generic rule I see is almost like this:


[1] "KBUILD_" + (Executable Name) + "FLAGS" = (Internal-use Variable)

[2] (Executable Name)  + "FLAGS" = (User Interface via Command Line)


They also derive

[3] (Internal-use Variable)  =
  "KBUILD_" + (User Interface via Command Line)


The following is the current situation:


[1] Flags for $(CC)

   Internal use  User interface via command line
---
(common)   KBUILD_CFLAGS KCFLAGS
(builtin)  KBUILD_CFLAGS_KERNEL  CFLAGS_KERNEL
(module)   KBUILD_CFLAGS_MODULE  CFLAGS_MODULE



[2] Flags for $(AS)

   Internal use   User interface via command line
--
(common)   KBUILD_AFLAGS  KAFLAGS
(builtin)  KBUILD_AFLAGS_KERNEL   AFLAGS_KERNEL
(module)   KBUILD_AFLAGS_MODULE   AFLAGS_MODULE


[3] Flags for $(CPP)

   Internal use User interface via command line
--
(common)   KBUILD_CPPFLAGSKCPPFLAGS



[4] Flags for $(LD)

   Internal use User interface via command line
--

(builtin)   [None]  #1 [None]
(module)   KBUILD_LDFLAGS_MODULE  LDFLAGS_MODULE


  #1 (LDFLAGS_vmlinux is used for internal variable for builtin)


[5] Flags for HOSTCC, HOSTCXX

Internal use  User interface via command line
-
C HOSTCFLAGS  [None]
C++   HOSTCXXFLAGS[None]
Link  HOSTLDFLAGS [None]
Library   HOST_LOADLIBES  [None]



KCFLAGS, KAFLAGS, KCPPFLAGS are exceptions.
[5] is also an exception.




A consistent way could be

[5] Flags for HOSTCC, HOSTCXX

Internal use  User interface via command line
-
C   KBUILD_HOSTCFLAGS HOSTCFLAGS
C++ KBUILD_HOSTCXXFLAGS   HOSTCXXFLAGS
LinkKBUILD_HOSTLDFLAGSHOSTLDFLAGS
Lib KBUILD_HOSTLDLIBS HOSTLDLIBS




Documentation/kbuild/kbuild.txt lists user interface parameters.
It is difficult to change them.  (probably, not allowed)



Documentation/kbuild/makefiles.txt lists Make variables
used in kernel sources.  So, it is easier to rename them.

Only the problem would be external modules that compile
their own host-programs with own flags. It is rare.
Anyway, 

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Masahiro Yamada]

2018-02-28 2:45 GMT+09:00 Josh Poimboeuf :
> On Mon, Feb 26, 2018 at 07:41:45PM +0100, Robin Jarry wrote:
>> This patchset allows to build host programs that depend on external libs
>> installed in non standard locations (i.e. not in /usr/include, /usr/lib,
>> etc.).  For now, the only way is to force HOSTCC to include both the
>> path to the host compiler and the build flags.
>>
>> I have encountered this issue when building linux into the buildroot
>> framework. host-* versions of libs may be compiled and installed in a
>> host staging dir removing the need to install them on the build system.
>>
>> I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
>> are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
>> HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
>> Documentation/kbuild/makefiles.txt).  And I didn't want to have even
>> longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
>> happily make a v3.
>
> In Documentation/kbuild/kbuild.txt, we have the following environment
> variables:
>
>   KCFLAGS
>   --
>   Additional options to the C compiler (for built-in and modules).
>
>   CFLAGS_KERNEL
>   --
>   Additional options for $(CC) when used to compile
>   code that is compiled as built-in.
>
>   CFLAGS_MODULE
>   --
>   Additional module specific options to use for $(CC).
>
>   LDFLAGS_MODULE
>   --
>   Additional options used for $(LD) when linking modules.
>
>   LDFLAGS_vmlinux
>   --
>   Additional options passed to final link of vmlinux.
>
> So instead of
>
>   HOST_CFLAGS
>   HOST_LDFLAGS
>
> maybe it would be more consistent to call them
>
>   CFLAGS_HOST
>   LDFLAGS_HOST
>
> ?
>
> Also, the new environment variables should be documented in the above
> file.
>
> --
> Josh



A generic rule I see is almost like this:


[1] "KBUILD_" + (Executable Name) + "FLAGS" = (Internal-use Variable)

[2] (Executable Name)  + "FLAGS" = (User Interface via Command Line)


They also derive

[3] (Internal-use Variable)  =
  "KBUILD_" + (User Interface via Command Line)


The following is the current situation:


[1] Flags for $(CC)

   Internal use  User interface via command line
---
(common)   KBUILD_CFLAGS KCFLAGS
(builtin)  KBUILD_CFLAGS_KERNEL  CFLAGS_KERNEL
(module)   KBUILD_CFLAGS_MODULE  CFLAGS_MODULE



[2] Flags for $(AS)

   Internal use   User interface via command line
--
(common)   KBUILD_AFLAGS  KAFLAGS
(builtin)  KBUILD_AFLAGS_KERNEL   AFLAGS_KERNEL
(module)   KBUILD_AFLAGS_MODULE   AFLAGS_MODULE


[3] Flags for $(CPP)

   Internal use User interface via command line
--
(common)   KBUILD_CPPFLAGSKCPPFLAGS



[4] Flags for $(LD)

   Internal use User interface via command line
--

(builtin)   [None]  #1 [None]
(module)   KBUILD_LDFLAGS_MODULE  LDFLAGS_MODULE


  #1 (LDFLAGS_vmlinux is used for internal variable for builtin)


[5] Flags for HOSTCC, HOSTCXX

Internal use  User interface via command line
-
C HOSTCFLAGS  [None]
C++   HOSTCXXFLAGS[None]
Link  HOSTLDFLAGS [None]
Library   HOST_LOADLIBES  [None]



KCFLAGS, KAFLAGS, KCPPFLAGS are exceptions.
[5] is also an exception.




A consistent way could be

[5] Flags for HOSTCC, HOSTCXX

Internal use  User interface via command line
-
C   KBUILD_HOSTCFLAGS HOSTCFLAGS
C++ KBUILD_HOSTCXXFLAGS   HOSTCXXFLAGS
LinkKBUILD_HOSTLDFLAGSHOSTLDFLAGS
Lib KBUILD_HOSTLDLIBS HOSTLDLIBS




Documentation/kbuild/kbuild.txt lists user interface parameters.
It is difficult to change them.  (probably, not allowed)



Documentation/kbuild/makefiles.txt lists Make variables
used in kernel sources.  So, it is easier to rename them.

Only the problem would be external modules that compile
their own host-programs with own flags. It is rare.
Anyway, external modules are often 

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Randy Dunlap]

On 02/27/2018 01:38 PM, Josh Poimboeuf wrote:
> On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote:
>> 2018-02-27, Josh Poimboeuf:
>>> In Documentation/kbuild/kbuild.txt, we have the following environment
>>> variables:
>>>
>>>   KCFLAGS
>>>   --
>>>   Additional options to the C compiler (for built-in and modules).
>>>   
>>>   CFLAGS_KERNEL
>>>   --
>>>   Additional options for $(CC) when used to compile
>>>   code that is compiled as built-in.
>>>   
>>>   CFLAGS_MODULE
>>>   --
>>>   Additional module specific options to use for $(CC).
>>>   
>>>   LDFLAGS_MODULE
>>>   --
>>>   Additional options used for $(LD) when linking modules.
>>>   
>>>   LDFLAGS_vmlinux
>>>   --
>>>   Additional options passed to final link of vmlinux.
>>>
>>> So instead of
>>>
>>>   HOST_CFLAGS
>>>   HOST_LDFLAGS
>>>
>>> maybe it would be more consistent to call them
>>>
>>>   CFLAGS_HOST
>>>   LDFLAGS_HOST
>>>
>>> ?
>>
>> I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!
>>
>>> Also, the new environment variables should be documented in the above
>>> file.
>>
>> Sure, I'll do that. However, I feel like I should also leave the
>> paragraph in Documentation/admin-guide/README.txt.
>>
>> What do you think?
> 
> [ Adding Jon Corbet to CC in case he has an opinion. ]
> 
> I think that paragraph in the admin guide seems a bit out of place,
> because that file only seems to cover the most common cases.
> 
> No other env variables are described in that file (and some of the
> previously existing env variables are much more likely to be used than
> these new ones anyway).
> 
> It might be a good idea to instead just add a reference to kbuild.txt,
> suggesting the user refer to that file if they want to learn more about
> what env variables can be used to customize the build.

(IMHO :)  I agree, the addition to admin-guide/README.rst (not .txt) is in
the wrong place, although it could contain a pointer to kbuild/ like Josh says.

And if you do move that text to kbuild/, please change "non standard" to
"non-standard" in 2 places.

thanks,
-- 
~Randy

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Randy Dunlap]

On 02/27/2018 01:38 PM, Josh Poimboeuf wrote:
> On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote:
>> 2018-02-27, Josh Poimboeuf:
>>> In Documentation/kbuild/kbuild.txt, we have the following environment
>>> variables:
>>>
>>>   KCFLAGS
>>>   --
>>>   Additional options to the C compiler (for built-in and modules).
>>>   
>>>   CFLAGS_KERNEL
>>>   --
>>>   Additional options for $(CC) when used to compile
>>>   code that is compiled as built-in.
>>>   
>>>   CFLAGS_MODULE
>>>   --
>>>   Additional module specific options to use for $(CC).
>>>   
>>>   LDFLAGS_MODULE
>>>   --
>>>   Additional options used for $(LD) when linking modules.
>>>   
>>>   LDFLAGS_vmlinux
>>>   --
>>>   Additional options passed to final link of vmlinux.
>>>
>>> So instead of
>>>
>>>   HOST_CFLAGS
>>>   HOST_LDFLAGS
>>>
>>> maybe it would be more consistent to call them
>>>
>>>   CFLAGS_HOST
>>>   LDFLAGS_HOST
>>>
>>> ?
>>
>> I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!
>>
>>> Also, the new environment variables should be documented in the above
>>> file.
>>
>> Sure, I'll do that. However, I feel like I should also leave the
>> paragraph in Documentation/admin-guide/README.txt.
>>
>> What do you think?
> 
> [ Adding Jon Corbet to CC in case he has an opinion. ]
> 
> I think that paragraph in the admin guide seems a bit out of place,
> because that file only seems to cover the most common cases.
> 
> No other env variables are described in that file (and some of the
> previously existing env variables are much more likely to be used than
> these new ones anyway).
> 
> It might be a good idea to instead just add a reference to kbuild.txt,
> suggesting the user refer to that file if they want to learn more about
> what env variables can be used to customize the build.

(IMHO :)  I agree, the addition to admin-guide/README.rst (not .txt) is in
the wrong place, although it could contain a pointer to kbuild/ like Josh says.

And if you do move that text to kbuild/, please change "non standard" to
"non-standard" in 2 places.

thanks,
-- 
~Randy

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Josh Poimboeuf]

On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote:
> 2018-02-27, Josh Poimboeuf:
> > In Documentation/kbuild/kbuild.txt, we have the following environment
> > variables:
> > 
> >   KCFLAGS
> >   --
> >   Additional options to the C compiler (for built-in and modules).
> >   
> >   CFLAGS_KERNEL
> >   --
> >   Additional options for $(CC) when used to compile
> >   code that is compiled as built-in.
> >   
> >   CFLAGS_MODULE
> >   --
> >   Additional module specific options to use for $(CC).
> >   
> >   LDFLAGS_MODULE
> >   --
> >   Additional options used for $(LD) when linking modules.
> >   
> >   LDFLAGS_vmlinux
> >   --
> >   Additional options passed to final link of vmlinux.
> > 
> > So instead of
> > 
> >   HOST_CFLAGS
> >   HOST_LDFLAGS
> > 
> > maybe it would be more consistent to call them
> > 
> >   CFLAGS_HOST
> >   LDFLAGS_HOST
> > 
> > ?
> 
> I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!
> 
> > Also, the new environment variables should be documented in the above
> > file.
> 
> Sure, I'll do that. However, I feel like I should also leave the
> paragraph in Documentation/admin-guide/README.txt.
> 
> What do you think?

[ Adding Jon Corbet to CC in case he has an opinion. ]

I think that paragraph in the admin guide seems a bit out of place,
because that file only seems to cover the most common cases.

No other env variables are described in that file (and some of the
previously existing env variables are much more likely to be used than
these new ones anyway).

It might be a good idea to instead just add a reference to kbuild.txt,
suggesting the user refer to that file if they want to learn more about
what env variables can be used to customize the build.

-- 
Josh

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Josh Poimboeuf]

On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote:
> 2018-02-27, Josh Poimboeuf:
> > In Documentation/kbuild/kbuild.txt, we have the following environment
> > variables:
> > 
> >   KCFLAGS
> >   --
> >   Additional options to the C compiler (for built-in and modules).
> >   
> >   CFLAGS_KERNEL
> >   --
> >   Additional options for $(CC) when used to compile
> >   code that is compiled as built-in.
> >   
> >   CFLAGS_MODULE
> >   --
> >   Additional module specific options to use for $(CC).
> >   
> >   LDFLAGS_MODULE
> >   --
> >   Additional options used for $(LD) when linking modules.
> >   
> >   LDFLAGS_vmlinux
> >   --
> >   Additional options passed to final link of vmlinux.
> > 
> > So instead of
> > 
> >   HOST_CFLAGS
> >   HOST_LDFLAGS
> > 
> > maybe it would be more consistent to call them
> > 
> >   CFLAGS_HOST
> >   LDFLAGS_HOST
> > 
> > ?
> 
> I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!
> 
> > Also, the new environment variables should be documented in the above
> > file.
> 
> Sure, I'll do that. However, I feel like I should also leave the
> paragraph in Documentation/admin-guide/README.txt.
> 
> What do you think?

[ Adding Jon Corbet to CC in case he has an opinion. ]

I think that paragraph in the admin guide seems a bit out of place,
because that file only seems to cover the most common cases.

No other env variables are described in that file (and some of the
previously existing env variables are much more likely to be used than
these new ones anyway).

It might be a good idea to instead just add a reference to kbuild.txt,
suggesting the user refer to that file if they want to learn more about
what env variables can be used to customize the build.

-- 
Josh

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

2018-02-27, Josh Poimboeuf:
> In Documentation/kbuild/kbuild.txt, we have the following environment
> variables:
> 
>   KCFLAGS
>   --
>   Additional options to the C compiler (for built-in and modules).
>   
>   CFLAGS_KERNEL
>   --
>   Additional options for $(CC) when used to compile
>   code that is compiled as built-in.
>   
>   CFLAGS_MODULE
>   --
>   Additional module specific options to use for $(CC).
>   
>   LDFLAGS_MODULE
>   --
>   Additional options used for $(LD) when linking modules.
>   
>   LDFLAGS_vmlinux
>   --
>   Additional options passed to final link of vmlinux.
> 
> So instead of
> 
>   HOST_CFLAGS
>   HOST_LDFLAGS
> 
> maybe it would be more consistent to call them
> 
>   CFLAGS_HOST
>   LDFLAGS_HOST
> 
> ?

I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!

> Also, the new environment variables should be documented in the above
> file.

Sure, I'll do that. However, I feel like I should also leave the
paragraph in Documentation/admin-guide/README.txt.

What do you think?

-- 
Robin

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

2018-02-27, Josh Poimboeuf:
> In Documentation/kbuild/kbuild.txt, we have the following environment
> variables:
> 
>   KCFLAGS
>   --
>   Additional options to the C compiler (for built-in and modules).
>   
>   CFLAGS_KERNEL
>   --
>   Additional options for $(CC) when used to compile
>   code that is compiled as built-in.
>   
>   CFLAGS_MODULE
>   --
>   Additional module specific options to use for $(CC).
>   
>   LDFLAGS_MODULE
>   --
>   Additional options used for $(LD) when linking modules.
>   
>   LDFLAGS_vmlinux
>   --
>   Additional options passed to final link of vmlinux.
> 
> So instead of
> 
>   HOST_CFLAGS
>   HOST_LDFLAGS
> 
> maybe it would be more consistent to call them
> 
>   CFLAGS_HOST
>   LDFLAGS_HOST
> 
> ?

I had missed this file. Indeed {C,LD}FLAGS_HOST are much less confusing!

> Also, the new environment variables should be documented in the above
> file.

Sure, I'll do that. However, I feel like I should also leave the
paragraph in Documentation/admin-guide/README.txt.

What do you think?

-- 
Robin

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Josh Poimboeuf]

On Mon, Feb 26, 2018 at 07:41:45PM +0100, Robin Jarry wrote:
> This patchset allows to build host programs that depend on external libs
> installed in non standard locations (i.e. not in /usr/include, /usr/lib,
> etc.).  For now, the only way is to force HOSTCC to include both the
> path to the host compiler and the build flags.
> 
> I have encountered this issue when building linux into the buildroot
> framework. host-* versions of libs may be compiled and installed in a
> host staging dir removing the need to install them on the build system.
> 
> I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
> are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
> HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
> Documentation/kbuild/makefiles.txt).  And I didn't want to have even
> longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
> happily make a v3.

In Documentation/kbuild/kbuild.txt, we have the following environment
variables:

  KCFLAGS
  --
  Additional options to the C compiler (for built-in and modules).
  
  CFLAGS_KERNEL
  --
  Additional options for $(CC) when used to compile
  code that is compiled as built-in.
  
  CFLAGS_MODULE
  --
  Additional module specific options to use for $(CC).
  
  LDFLAGS_MODULE
  --
  Additional options used for $(LD) when linking modules.
  
  LDFLAGS_vmlinux
  --
  Additional options passed to final link of vmlinux.

So instead of

  HOST_CFLAGS
  HOST_LDFLAGS

maybe it would be more consistent to call them

  CFLAGS_HOST
  LDFLAGS_HOST

?

Also, the new environment variables should be documented in the above
file.

-- 
Josh

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Josh Poimboeuf]

On Mon, Feb 26, 2018 at 07:41:45PM +0100, Robin Jarry wrote:
> This patchset allows to build host programs that depend on external libs
> installed in non standard locations (i.e. not in /usr/include, /usr/lib,
> etc.).  For now, the only way is to force HOSTCC to include both the
> path to the host compiler and the build flags.
> 
> I have encountered this issue when building linux into the buildroot
> framework. host-* versions of libs may be compiled and installed in a
> host staging dir removing the need to install them on the build system.
> 
> I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
> are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
> HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
> Documentation/kbuild/makefiles.txt).  And I didn't want to have even
> longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
> happily make a v3.

In Documentation/kbuild/kbuild.txt, we have the following environment
variables:

  KCFLAGS
  --
  Additional options to the C compiler (for built-in and modules).
  
  CFLAGS_KERNEL
  --
  Additional options for $(CC) when used to compile
  code that is compiled as built-in.
  
  CFLAGS_MODULE
  --
  Additional module specific options to use for $(CC).
  
  LDFLAGS_MODULE
  --
  Additional options used for $(LD) when linking modules.
  
  LDFLAGS_vmlinux
  --
  Additional options passed to final link of vmlinux.

So instead of

  HOST_CFLAGS
  HOST_LDFLAGS

maybe it would be more consistent to call them

  CFLAGS_HOST
  LDFLAGS_HOST

?

Also, the new environment variables should be documented in the above
file.

-- 
Josh

[PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

This patchset allows to build host programs that depend on external libs
installed in non standard locations (i.e. not in /usr/include, /usr/lib,
etc.).  For now, the only way is to force HOSTCC to include both the
path to the host compiler and the build flags.

I have encountered this issue when building linux into the buildroot
framework. host-* versions of libs may be compiled and installed in a
host staging dir removing the need to install them on the build system.

I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
Documentation/kbuild/makefiles.txt).  And I didn't want to have even
longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
happily make a v3.

Comments are welcome.

Changes since v1:
 - Fix typos.
 - Do not use HOST_EXTRA*FLAGS. Add new user specifiable variables.
 - Pass HOSTLDFLAGS to build single .c programs.
 - Build objtool with host flags.

Robin Jarry (3):
  kbuild: introduce HOST_{C,LD}FLAGS
  kbuild: use HOSTLDFLAGS for single .c executables
  objtool: use global host flags for compilation

 Documentation/admin-guide/README.rst | 16 
 Makefile |  9 +
 scripts/Makefile.host|  2 +-
 tools/objtool/Makefile   |  4 ++--
 4 files changed, 24 insertions(+), 7 deletions(-)

-- 
2.11.0

[PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

[Robin Jarry]

This patchset allows to build host programs that depend on external libs
installed in non standard locations (i.e. not in /usr/include, /usr/lib,
etc.).  For now, the only way is to force HOSTCC to include both the
path to the host compiler and the build flags.

I have encountered this issue when building linux into the buildroot
framework. host-* versions of libs may be compiled and installed in a
host staging dir removing the need to install them on the build system.

I'm not really satisfied with the new HOST_{C,LD}FLAGS variables.  They
are too similar to HOST{C,LD}FLAGS and I find them confusing.  However,
HOST_EXTRA*FLAGS are already reserved for local use in makefiles (see
Documentation/kbuild/makefiles.txt).  And I didn't want to have even
longer USER_HOST_*FLAGS.  If someone has a better proposition, I'll
happily make a v3.

Comments are welcome.

Changes since v1:
 - Fix typos.
 - Do not use HOST_EXTRA*FLAGS. Add new user specifiable variables.
 - Pass HOSTLDFLAGS to build single .c programs.
 - Build objtool with host flags.

Robin Jarry (3):
  kbuild: introduce HOST_{C,LD}FLAGS
  kbuild: use HOSTLDFLAGS for single .c executables
  objtool: use global host flags for compilation

 Documentation/admin-guide/README.rst | 16 
 Makefile |  9 +
 scripts/Makefile.host|  2 +-
 tools/objtool/Makefile   |  4 ++--
 4 files changed, 24 insertions(+), 7 deletions(-)

-- 
2.11.0