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

[Wolfgang Denk <wd@denx.de>]

In message <47F3AD74.4000900@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. And
we should really make sure that U-Boot header files get used only iff
there is no corresponding host header  file,  and  in  this  case  we
should make sure that this is intentional.

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).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9