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

Bartlomiej Sieka
2008-04-03T16:33:31Z

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