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

[Andy Fleming]

On Thu, Apr 3, 2008 at 1:36 PM, Scott Wood <scottwood at freescale.com> wrote:
> On Thu, Apr 03, 2008 at 08:26:23PM +0200, Wolfgang Denk wrote:
>  > In message <47F506DB.6010506 at semihalf.com> you wrote:
>  > >
>  > > 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.
>  >
>  > But you, you should. Note that we are talking about host tools  here,
>  > i.  e.  stuff that is supposed to run in the host environment. Assume
>  > your're building for a big-endian, 32 bit Power system.  Assume  your
>  > host is a little-endian x86_64 system.
>  >
>  > Even simple tungs like a printf() require that you include the correct
>  > host header files as you will link your host application against the
>  > host libraries, too.
>
>  That's because printf() is from the host's libraries.  lib_generic/md5.c
>  is not a host-provided library, so you don't want to use a host-provided
>  header.

I agree with this.  Ideally, we should search system headers when we
want them, and u-boot headers when we want *them*.  However, my
Make-fu is not strong enough to figure that one out.


>
>  It is much more important to be robust against random crap in
>  /usr/include (something u-boot can't control) than changes in the u-boot
>  tree itself.

Well, IMNSHO, renaming the internal header to u-boot-md5.h solves the
problem with a high degree of robustness (random non-u-boot packages
are unlikely to install a header with u-boot in the name), and avoids
the dangers of relative path lookups.  It so happens I already sent a
patch to do that...  :)

That said, if we could figure out how to rejigger the Makefile so that
it found u-boot's md5.h first, that would be better.  I suspect that
involves a similar patch, though.  These are the header categories:

1) U-Boot headers only meant for target compilation
2) System headers
3) U-Boot headers meant for host compilation (probably for both host and target)

When we're building for the target, we just don't search the system.
But for host compilation, we want to exclude #1.  To do that, we'd
have to identify every header which should never be compiled on the
host, and move it into another directory which won't get searched when
we're using HOST_CC.

Personally, I suspect category 3 is much smaller than category 1, so
it's probably easier to uniquify the smaller category somehow.  We
could, for instance, also just identify those files and move them into
include/generic/ or somesuch.

Andy