[U-Boot-Users] [patch] do not use linux/string.h in sha1.c on hosts

linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
Signed-Off-By: Mike Frysinger vapier@gentoo.org --- diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c index 08ffa6b..d04cba7 100644 --- a/lib_generic/sha1.c +++ b/lib_generic/sha1.c @@ -29,7 +29,11 @@ #define _CRT_SECURE_NO_DEPRECATE 1 #endif
+#ifndef USE_HOSTCC #include <linux/string.h> +#else +#include <string.h> +#endif #include "sha1.h"
/* diff --git a/tools/easylogo/Makefile b/tools/easylogo/Makefile index 292344a..566b125 100644 --- a/tools/easylogo/Makefile +++ b/tools/easylogo/Makefile @@ -1,2 +1,8 @@ -all: easylogo.c - gcc easylogo.c -o easylogo +CFLAGS += -Wall + +all: easylogo + +clean: + rm -f easylogo *.o + +.PHONY: all clean diff --git a/tools/easylogo/easylogo.c b/tools/easylogo/easylogo.c index 9f1d1ff..c69f012 100644 --- a/tools/easylogo/easylogo.c +++ b/tools/easylogo/easylogo.c @@ -8,6 +8,8 @@ */
#include <stdio.h> +#include <stdlib.h> +#include <string.h>
#pragma pack(1)
@@ -41,7 +43,7 @@ typedef struct { } yuyv_t ;
typedef struct { - unsigned char *data, + void *data, *palette ; int width, height, @@ -125,6 +127,16 @@ void printlogo_yuyv (unsigned short *data, int w, int h) } }
+static inline unsigned short le16_to_cpu (unsigned short val) +{ + union { + unsigned char pval[2]; + unsigned short val; + } swapped; + swapped.val = val; + return (swapped.pval[1] << 8) + swapped.pval[0]; +} + int image_load_tga (image_t *image, char *filename) { FILE *file ; @@ -138,6 +150,14 @@ int image_load_tga (image_t *image, char *filename)
fread(&header, sizeof(header), 1, file);
+ /* byte swap: tga is little endian, host is ??? */ + header.ColorMapOrigin = le16_to_cpu (header.ColorMapOrigin); + header.ColorMapLenght = le16_to_cpu (header.ColorMapLenght); + header.ImageXOrigin = le16_to_cpu (header.ImageXOrigin); + header.ImageYOrigin = le16_to_cpu (header.ImageYOrigin); + header.ImageWidth = le16_to_cpu (header.ImageWidth); + header.ImageHeight = le16_to_cpu (header.ImageHeight); + image->width = header.ImageWidth ; image->height = header.ImageHeight ;
@@ -352,9 +372,10 @@ int main (int argc, char *argv[]) strcpy (varname, argv[2]); else { - int pos = strchr(inputfile, '.'); + char *dot = strchr(inputfile, '.'); + int pos = dot - inputfile;
- if (pos >= 0) + if (dot) { strncpy (varname, inputfile, pos); varname[pos] = 0 ; @@ -365,13 +386,15 @@ int main (int argc, char *argv[]) strcpy (outputfile, argv[3]); else { - int pos = strchr (varname, '.'); + char *dot = strchr (varname, '.'); + int pos = dot - varname;
- if (pos > 0) + if (dot) { char app[DEF_FILELEN] ;
strncpy(app, varname, pos); + app[pos] = 0; sprintf(outputfile, "%s.h", app); } } @@ -389,6 +412,8 @@ int main (int argc, char *argv[]) return -1 ; }
+ setbuf(stdout, NULL); + printf("Doing '%s' (%s) from '%s'...", outputfile, varname, inputfile);

On Monday 24 December 2007, Mike Frysinger wrote:
diff --git a/tools/easylogo/Makefile b/tools/easylogo/Makefile diff --git a/tools/easylogo/easylogo.c b/tools/easylogo/easylogo.c
blah, i thought i'd cut the patch before i appended, but that appears to not be the case. ignore all the hunks other than sha1.c as they've already been posted to the list. -mike

In message 200712241709.31277.vapier@gentoo.org you wrote:
linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
But IIRC mkimage does not use any sha1 code ...
Best regards,
Wolfgang Denk

On Tuesday 25 December 2007, Wolfgang Denk wrote:
In message 200712241709.31277.vapier@gentoo.org you wrote:
linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
Signed-Off-By: Mike Frysinger vapier@gentoo.org --- diff --git a/tools/Makefile b/tools/Makefile index e8e0280..0432253 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -136,7 +136,7 @@ $(obj)img2srec$(SFX): $(obj)img2srec.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@
-$(obj)mkimage$(SFX): $(obj)mkimage.o $(obj)crc32.o $(obj)sha1.o +$(obj)mkimage$(SFX): $(obj)mkimage.o $(obj)crc32.o $(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^ $(STRIP) $@

Mike Frysinger wrote:
On Tuesday 25 December 2007, Wolfgang Denk wrote:
In message 200712241709.31277.vapier@gentoo.org you wrote:
linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
It is likely we'll need sha1 support in mkimage for the new uImage format. Let's wait with this patch until mkimage extension to the new uImage format is settled down.
Regards, Bartlomiej

In message 4773FCEF.2040507@semihalf.com you wrote:
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
Indeed the Makefile contained a not needed reference.
It is likely we'll need sha1 support in mkimage for the new uImage format. Let's wait with this patch until mkimage extension to the new uImage format is settled down.
I'm not so sure. Maybe it's better to clean up now, and deal with the new image format requirements when we're at it. Please note that the mkimage code has recenty been added to the Linux kernel tree, and there the sha1 reference was also removed. I think it makes sense to keep both in sync...
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
In message 4773FCEF.2040507@semihalf.com you wrote:
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
Indeed the Makefile contained a not needed reference.
It is likely we'll need sha1 support in mkimage for the new uImage format. Let's wait with this patch until mkimage extension to the new uImage format is settled down.
I'm not so sure. Maybe it's better to clean up now, and deal with the new image format requirements when we're at it. Please note that the mkimage code has recenty been added to the Linux kernel tree, and there the sha1 reference was also removed. I think it makes sense to keep both in sync...
I think it makes sense, too.
I am fine with having the clean-up now, and adding sha1 later on when needed.
Regards, Barlomiej

On Thu, 27 Dec 2007 21:15:16 +0100 Wolfgang Denk wd@denx.de wrote:
In message 4773FCEF.2040507@semihalf.com you wrote:
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
Indeed the Makefile contained a not needed reference.
It is likely we'll need sha1 support in mkimage for the new uImage format. Let's wait with this patch until mkimage extension to the new uImage format is settled down.
I'm not so sure. Maybe it's better to clean up now, and deal with the new image format requirements when we're at it. Please note that the mkimage code has recenty been added to the Linux kernel tree, and there the sha1 reference was also removed. I think it makes sense to keep both in sync...
Actually, it hasn't been added yet. I've only sent out one round of patches so far. And those included the sha1.c code because of the exact same reason. I wanted to keep them in sync :)
josh

On Thursday 27 December 2007, Bartlomiej Sieka wrote:
Mike Frysinger wrote:
On Tuesday 25 December 2007, Wolfgang Denk wrote:
In message 200712241709.31277.vapier@gentoo.org you wrote:
linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
It is likely we'll need sha1 support in mkimage for the new uImage format. Let's wait with this patch until mkimage extension to the new uImage format is settled down.
pick one ... fix sha1.c or dont link it in. doesnt matter to me. -mike

In message 200712271342.58728.vapier@gentoo.org you wrote:
On Tuesday 25 December 2007, Wolfgang Denk wrote:
In message 200712241709.31277.vapier@gentoo.org you wrote:
linux/string.h is not a valid include outside of the kernel, so when compiling sha1.c for the host (for use with the `mkimage` host binary), the include needs to be changed to string.h.
But IIRC mkimage does not use any sha1 code ...
the Makefile claims otherwise ... patch attached to remove sha1.o from mkimage linking since it isnt actually used.
Signed-Off-By: Mike Frysinger vapier@gentoo.org
Applied. Thanks.
Best regards,
Wolfgang Denk
participants (4)
-
Bartlomiej Sieka
-
Josh Boyer
-
Mike Frysinger
-
Wolfgang Denk