Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
