[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Bartlomiej Sieka]

Wolfgang Denk wrote:
> In message <47F3AD74.4000900 at semihalf.com> you wrote:
>> I think that generally it is a better idea to use U-Boot's includes when
>> building for the host system, as this gives us better control over what
>> exactly gets included. But then on the other hand, tools/Makefils has this:
> 
> But U-boot doesn't have the knowledge about the target system that the
> target distribution has.
> 
>> CPPFLAGS   = -idirafter $(SRCTREE)/include \
>> 		-idirafter $(OBJTREE)/include2 \
>> 		-idirafter $(OBJTREE)/include \
>>
>> Could anyone comment on the reasons why we try U-Boot's includes after
>> system includes? Perhaps it would be a good idea to reverse the order --
>> see below for a quick RFC patch (compile-tested on two arm and two ppc
>> boards, each arch with and without CONFIG_FIT enabled).
> 
> Don't! I guess you tried just one configuration, and probably not even
> building on a 32 versus a 64 bit host system.
> 
> When building tools with the host compiler that are supposed  to  run
> on  the host system we should always use the host's header files.

I think this makes sense for code that we for example link from host's
standard libraries. But for code compiled from files from the U-Boot
tree (like lib_generic/md5.c), we shouldn't include host's header files.

> 
> The current problem comes from the fact  that  old  versions  of  the
> cyrus-sasl-devel  package  install  a  /usr/include/md5.h  file which
> probably NOT intended for direct use, but only within the context  of
> the  SASL  package; recent versions of the same package install it in
> /usr/include/sasl/md5.h instead.
> 
> To solve this problem I see three solutions:
> 
> 1) Fix the broken host systems for example by installing more recent
>    versions of the cyrus-sasl-devel package; this would be best, but
>    is unfortunately not possible everywhere.
> 2) Use relative file names (as suggested by Kumar) or similar methods
>    to make sure we pick up the md5.h header file from a local
>    directory instead from /usr/include.
> 3) Rename md5.h to make sure we use a pick up our own file instead of
>    some unrelated file which happens to have the same name.
> 
> My vote goes for 3).

2) seems to be more robust, though -- 3) works until someone installs a
system header file which happens to have the name that we came up with
for the U-Boot's own header file. Also, we used 2) for libfdt compiled
for mkimage.

Regards,
Bartlomiej