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