From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bartlomiej Sieka <tur@semihalf.com>
Date: Thu, 03 Apr 2008 18:33:31 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080402185750.62979243AB@gemini.denx.de>
References: <20080402185750.62979243AB@gemini.denx.de>
Message-ID: <47F506DB.6010506@semihalf.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Wolfgang Denk wrote:
> 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.

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