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