[1/3] package/Makefile.in: Use '-isystem' instead of '-I' in HOST_CFLAGS globally

Message ID 20180831142024.27548-1-david.degrave@mind.be
State Changes Requested
Headers show
Series
  • [1/3] package/Makefile.in: Use '-isystem' instead of '-I' in HOST_CFLAGS globally
Related show

Commit Message

David De Grave Aug. 31, 2018, 2:20 p.m.
As the $(HOST_DIR) is the buildroot's system install directory, and that
all the builds should use that one in priority (it's even mandatory for
uboot and linux), it make sense to use '-isystem' to ensure it is searched
right before the system directories and still let the possibility for the
packages to use specific ones using '-I'.

 Now, changing '-I' into '-isystem' carries the risk that a package will add
'-I/usr/include' to CFLAGS and thus give priority to system headers over
host headers. However, this turns out not to be the case, because gcc will
remove the '-I' options that add system includes:

  $ gcc -v -c -isystem $PWD/output/host/include -I/usr/include \
    support/kconfig/expr.c
  ...
  ignoring duplicate directory "/usr/include" as it is a non-system \
    directory that duplicates a system directory
  #include "..." search starts here:
  #include <...> search starts here:
   {output}/host/include
   /usr/lib/gcc/x86_64-linux-gnu/8/include
   /usr/local/include
   /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
   /usr/include/x86_64-linux-gnu
   /usr/include
  End of search list.
  ...

Signed-off-by: David De Grave (Essensium/Mind) <david.degrave@mind.be>
---
 package/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Thomas Petazzoni Sept. 9, 2018, 1:32 p.m. | #1
Hello David,

On Fri, 31 Aug 2018 16:20:22 +0200, David De Grave (Essensium/Mind)
wrote:
>  As the $(HOST_DIR) is the buildroot's system install directory, and that
> all the builds should use that one in priority (it's even mandatory for
> uboot and linux), it make sense to use '-isystem' to ensure it is searched
> right before the system directories and still let the possibility for the
> packages to use specific ones using '-I'.

Could you give a few more details about the motivation for this change.
Is it just because it is "cleaner" to refer to Buildroot
$(HOST_DIR)/include using -isystem, or does this fix some actual
problem/build issue ?

Doing such a change is pretty invasive, it could potentially cause
some build failures, so I'd like to understand the motivation.

Thanks!

Thomas
Arnout Vandecappelle Sept. 10, 2018, 9:51 a.m. | #2
On 09/09/2018 15:32, Thomas Petazzoni wrote:
> Hello David,
> 
> On Fri, 31 Aug 2018 16:20:22 +0200, David De Grave (Essensium/Mind)
> wrote:
>>  As the $(HOST_DIR) is the buildroot's system install directory, and that
>> all the builds should use that one in priority (it's even mandatory for
>> uboot and linux), it make sense to use '-isystem' to ensure it is searched
>> right before the system directories and still let the possibility for the
>> packages to use specific ones using '-I'.
> 
> Could you give a few more details about the motivation for this change.
> Is it just because it is "cleaner" to refer to Buildroot
> $(HOST_DIR)/include using -isystem, or does this fix some actual
> problem/build issue ?

 It fixes the existing problem for u-boot and linux in a more generic way. Also,
the same issue might exist for any host package that we have. The exported
headers are often in an 'include' directory that is accessed with a -I flag. If
that -I flag is added after the CFLAGS passed in by us, then the compiler will
first find the host-installed headers rather than the local headers.
Autobuilders will usually not find such an issue, because they have a rather
minimal set of devel packages installed on the system.

 It's true that these issues are rare: normally the local -I flags are added
*before* the CFLAGS passed in by the user. However, I'm pretty sure that
packages do exist that don't do this (e.g. if the Makefile just does 'CFLAGS +=
...'). It's pretty hard to detect such cases, because *usually* it doesn't give
an error (because the system headers are probably compatible with the local
headers).

 Regards,
 Arnout

> 
> Doing such a change is pretty invasive, it could potentially cause
> some build failures, so I'd like to understand the motivation.
> 
> Thanks!
> 
> Thomas
>
David De Grave Sept. 10, 2018, 1 p.m. | #3
Hello Thomas, Arnout,

On Mon, Sep 10, 2018 at 11:51 AM, Arnout Vandecappelle <arnout@mind.be>
wrote:


> > Could you give a few more details about the motivation for this change.
> > Is it just because it is "cleaner" to refer to Buildroot
> > $(HOST_DIR)/include using -isystem, or does this fix some actual
> > problem/build issue ?
>

More than making things cleaner/logic, it fixes a build issue I've with the
beagle bone
black's Linux kernel: https://github.com/beagleboard/linux.git

They implemented a driver who handle DTBs overlays and what they call
"capes"
(PCB extensions to the bbb mother board). Since the update of the DTC
package few
weeks ago, my build is throwing compilation errors in linux when it starts
to compile
their own version of the dtc. Due to the way they include their headers,
some of them
were taken from the host while some others are taken from local dir.
Moreover, their
dtc version use different names in their defines (a missing underscore) and
this why
at a certain point, it throws a "function redefinition error". Maybe other
kernels are
suffering from the same problem, I don't know...

I first fixed the issue by adding a patch to my project to change the
involved sources
in the Kernel tree...

But then I thought that other people may suffers from this problem too and
decided to
make it more generic by patching buildroot itself, so that I could save
them few hours
of investigations. This is why I submitted my first patch who applied the
same kind of
change in the linux.mk file.

Then, I discussed this with Arnout and we thought it would be even more
benefit to
make it global as it's already a requirement for uboot and now linux too.
Moreover it
sounds more logic/cleaner to make it that way, but that was not the main
idea.

So, that's why I submitted this patch series.

> Doing such a change is pretty invasive, it could potentially cause
> > some build failures, so I'd like to understand the motivation.
>

I understand, no problem :-)

Regards,
David.
Yann E. MORIN Oct. 21, 2018, 2:18 p.m. | #4
David, All,

On 2018-09-10 15:00 +0200, David De Grave spake thusly:
> Hello Thomas, Arnout,
> On Mon, Sep 10, 2018 at 11:51 AM, Arnout Vandecappelle < [1]arnout@mind.be> wrote:
>  
> 
>   > Could you give a few more details about the motivation for this change.
>   > Is it just because it is "cleaner" to refer to Buildroot
>   > $(HOST_DIR)/include using -isystem, or does this fix some actual
>   > problem/build issue ?
> 
> More than making things cleaner/logic, it fixes a build issue I've with the beagle bone
> black's Linux kernel: [2]https://github.com/beagleboard/linux.git
> They implemented a driver who handle DTBs overlays and what they call "capes"
> (PCB extensions to the bbb mother board). Since the update of the DTC package few
> weeks ago, my build is throwing compilation errors in linux when it starts to compile
> their own version of the dtc. Due to the way they include their headers, some of them
> were taken from the host while some others are taken from local dir. Moreover, their
> dtc version use different names in their defines (a missing underscore) and this why
> at a certain point, it throws a "function redefinition error". Maybe other kernels are
> suffering from the same problem, I don't know...
> I first fixed the issue by adding a patch to my project to change the involved sources
> in the Kernel tree...
> But then I thought that other people may suffers from this problem too and decided to
> make it more generic by patching buildroot itself, so that I could save them few hours
> of investigations. This is why I submitted my first patch who applied the same kind of
> change in the [3]linux.mk file.
> Then, I discussed this with Arnout and we thought it would be even more benefit to
> make it global as it's already a requirement for uboot and now linux too. Moreover it
> sounds more logic/cleaner to make it that way, but that was not the main idea.
> So, that's why I submitted this patch series.

The -isystem has already been tried, and lately resurfaced in another
thread, in which it was noticed that it broke at least a few packages,
please see:

    http://lists.busybox.net/pipermail/buildroot/2018-October/232615.html

So, before we reinstate the use of -isystem, a few packages will have to
be fixed first.

Thanks!

Regards,
Yann E. MORIN.

>   > Doing such a change is pretty invasive, it could potentially cause
>   > some build failures, so I'd like to understand the motivation.
> 
> I understand, no problem :-)
> Regards,
> David.
> --
> 
> +--------------------------------------------------------------------------------------------------------+
> |        | David De Grave                                                                                |
> |   | Senior Embedded Software Developer                                                            |
> |        | Gsm : +32(0)496.364.960 | Tel : +32-16-28.65.00 | Fax : +32-16-28a.65.01  |
> |        | [4]Essensium-Mind - Gaston Geenslaan 9, B-3001 Leuven, Belgium                                |
> +--------------------------------------------------------------------------------------------------------+
> 
> Links:
> 1. mailto:arnout@mind.be
> 2. https://github.com/beagleboard/linux.git
> 3. http://linux.mk
> 4. https://www.mind.be/

> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Patch

diff --git a/package/Makefile.in b/package/Makefile.in
index 91b3e8f936..5ed70f0a65 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -223,7 +223,7 @@  UNZIP := $(shell which unzip || type -p unzip) -q
 
 APPLY_PATCHES = PATH=$(HOST_DIR)/bin:$$PATH support/scripts/apply-patches.sh $(if $(QUIET),-s)
 
-HOST_CPPFLAGS  = -I$(HOST_DIR)/include
+HOST_CPPFLAGS  = -isystem $(HOST_DIR)/include
 HOST_CFLAGS   ?= -O2
 HOST_CFLAGS   += $(HOST_CPPFLAGS)
 HOST_CXXFLAGS += $(HOST_CFLAGS)