Hello Gerhard.
>
> There is another issue for those who do
>
> make HOSTCC=${CROSS_COMPILE}gcc env
> (needs a HOSTSTRIP spec as well in recent mainline sources)
>
> to get an fw_printenv(1) binary that runs on the target (in
> contrast to the build machine). Some yocto recipes do this, to
> not re-invent how to build this tool or how to read and write the
> environment image.
>
> With your changes, the 'env' make target is gone, instead there
> is a 'tools-all' target but it has a wider scope, includes the
> BMP manipulation/conversion stuff and uses HOSTCC to build a
> bmp_logo(1) tool, which breaks in the mentioned use case (cross
> compiled bmp_logo(1) executable, empty bmp_logo.h header, aborted
> build sequence).
I did not know how "env" target have been used.
Your comments are highly appreciated!
I will revive "env" target at v5.
But whan I cannot understand is why HOSTCC must be tweaked.
(I am also asking this question in "Compiling fw_printenv tool" thread)
If fw_printenv must be always compiled with cross-tools,
I'd like to suggest to use $(CC) instead of $(HOSTCC)
in tools/env/Makefile.
> While testing your series I noticed a probably missing
> dependency: Running something different from 'make all' (or make
> without a target spec) after 'make <board>_config' won't work
> since the fixdeps(1) tool is missing. It's a "byproduct" of
> 'make all', afterwards other targets can get built separately.
> Is there a "preparation" step that one needs to take if not
> calling 'make all' immediately after configuration?
Good catch!
I will fix this problem at v5.
Best Regards
Masahiro Yamada
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
