On Fri, 2009-02-06 at 20:06 +0100, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <[email protected]> you wrote: > > Add a mkimage_win32.exe build target which can produce a native > > win32 mkimage executable using the MinGW toolchain. The > > mkimage_win32.exe binary is generated when the MINGW_COMPILE > > environment variable is defined. The mkimage_win32.exe binary > > can be used by those who use Windows as an OS build environment > > but don't use cygwin. > > Why do we need a new envrironment variable? Can we not follow the > standard pattern ansd use CROSS_COMPILE instead?
Most files can't be compiled with MinGW so if CROSS_COMPILE is set to a MinGW compile errors quickly occur in the build process. Also, it would be a bigger pain to compile u-boot + mkimage_win32.exe. Eg: export CROSS_COMPILE=powerpc-linux- export MINGW_COMPILE=i586-mingw32msvc- make vs export CROSS_COMPILE=i586-mingw32msvc- make cp tools/mkimage_win32.exe ~/ make clean export CROSS_COMPILE=powerpc-linux- make > > +Note: If you wish to generate a WIN32 version of the mkimage tool > > + using the MinGW toolchain (see http://www.mingw.org) you must > > + also set the MINGW_COMPILE environment variable, for example: > > + > > + $ export MINGW_COMPILE=i586-mingw32msvc- > > Why cannot we use CROSS_COMPILE=i586-mingw32msvc- ? > YOu can test for *mingw* easily, I think. > > > #if USE_HOSTCC > > +#ifndef __MINGW32__ > > #include <endian.h> > > +#endif > > How does MinGW handle byte order issues, then? bswap_XX functions were added in mingw_support.c. > > --- a/include/libfdt_env.h > > +++ b/include/libfdt_env.h > > @@ -24,8 +24,10 @@ > > #ifdef USE_HOSTCC > > #include <stdint.h> > > #include <string.h> > > +#ifndef __MINGW32__ > > #include <endian.h> > > #include <byteswap.h> > > +#endif /* __MINGW32__ */ > > Ditto - how is byte order handled? > > > +# Build native win32 mkimage if mingw compiler is specified > > +ifneq ($(MINGW_COMPILE),) > > You can test the content of CROSS_COMPILE here, too? > > > +/* > > + * Copyright 2008 Extreme Engrineering Solutions, Inc. > > Is this really the name of that company? Damn fingers... Thanks, Peter _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
