Skip to contentSkip to conversation

Fix host tool build breakage, take two

PATCH New Bartlomiej Sieka 10 participants 25 messages Mar 27, 2008 – Apr 14, 2008

lore
Share & tools
lore

Bartlomiej Sieka

author
#0 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Revert commit 87c8431f and fix build breakage so that the build continues to work on FC systems.

Signed-off-by Bartlomiej Sieka <[email protected]>

---
Patch tested on FC and kubuntu. Could people that reported Haavard's patch fixing the build for them try this one out and report back?

include/fdt.h +0 -4
index 39beada..48ccfd9 100644
@@ -3,10 +3,6 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef USE_HOSTCC
-#include <stdint.h>
-#endif
-
 struct fdt_header {
 	uint32_t magic;			 /* magic word FDT_MAGIC */
 	uint32_t totalsize;		 /* total size of DT block */
include/libfdt_env.h +4 -3
index 98c522a..ab5c301 100644
@@ -21,15 +21,16 @@
 #ifndef _LIBFDT_ENV_H
 #define _LIBFDT_ENV_H
 
-#include <stddef.h>
-#include <linux/types.h>
-#include <asm/byteorder.h>
 #ifdef USE_HOSTCC
+#include <stdint.h>
 #include <string.h>
 #else
 #include <linux/string.h>
+#include <linux/types.h>
 #endif /* USE_HOSTCC */
 
+#include <stddef.h>
+#include <asm/byteorder.h>
 extern struct fdt_header *fdt;  /* Pointer to the working fdt */
 
 #define fdt32_to_cpu(x)		__be32_to_cpu(x)
#1 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Hi Bartlomiej,

Quoted 7 lines · Bartlomiej Sieka

Revert commit 87c8431f and fix build breakage so that the build continues to work on FC systems.

Signed-off-by Bartlomiej Sieka <[email protected]>

---
Patch tested on FC and kubuntu. Could people that reported Haavard's patch fixing the build for them try this one out and report back?

Works fine on Debian.

Acked-by Markus Klotzbuecher <[email protected]>

Best regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de

#3 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Even with this patch I'm still having issues:

gcc -g -Wall -idirafter /tmp/u-boot-85xx/include -idirafter /tmp/u- boot-85xx/include2 -idirafter /tmp/u-boot-85xx/include - DTEXT_BASE=0xfff80000 -DUSE_HOSTCC -O -c -o image.o image.c In file included from image.c:73:
/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

- k

#4 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 6 lines · In message <[email protected]> you wrote:

Even with this patch I'm still having issues:

gcc -g -Wall -idirafter /tmp/u-boot-85xx/include -idirafter /tmp/u- boot-85xx/include2 -idirafter /tmp/u-boot-85xx/include - DTEXT_BASE=0xfff80000 -DUSE_HOSTCC -O -c -o image.o image.c In file included from image.c:73:

Which Linux distro are you running?

Quoted 8 lines

/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

Which package in your distro installs "/usr/include/md5.h" ?

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Being schizophrenic is better than living alone.
#5 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 10 lines · Wolfgang Denk

In message <EB0C2999-8BB8-4F0E-B3E4-

Quoted 6 lines · DE4C28EA97D9 at kernel.crashing.org> you wrote:

Even with this patch I'm still having issues:

gcc -g -Wall -idirafter /tmp/u-boot-85xx/include -idirafter /tmp/u- boot-85xx/include2 -idirafter /tmp/u-boot-85xx/include - DTEXT_BASE=0xfff80000 -DUSE_HOSTCC -O -c -o image.o image.c In file included from image.c:73:

Which Linux distro are you running?

RHEL WS 3

Quoted 10 lines
Quoted 8 lines

/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

Which package in your distro installs "/usr/include/md5.h" ?

cyrus-sasl-devel-2.1.15-10

- k

#6 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 24 lines · Kumar Gala
Quoted 10 lines · Wolfgang Denk

In message <EB0C2999-8BB8-4F0E-B3E4-

Quoted 6 lines · DE4C28EA97D9 at kernel.crashing.org> you wrote:

Even with this patch I'm still having issues:

gcc -g -Wall -idirafter /tmp/u-boot-85xx/include -idirafter /tmp/u- boot-85xx/include2 -idirafter /tmp/u-boot-85xx/include - DTEXT_BASE=0xfff80000 -DUSE_HOSTCC -O -c -o image.o image.c In file included from image.c:73:

Which Linux distro are you running?

RHEL WS 3

Quoted 9 lines
Quoted 8 lines

/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

Quoted 3 lines
Quoted 1 line

Which package in your distro installs "/usr/include/md5.h" ?

cyrus-sasl-devel-2.1.15-10

any ideas?

- k

#7 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Quoted 2 lines

Which Linux distro are you running?

RHEL WS 3

Oops.

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines

/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

Which package in your distro installs "/usr/include/md5.h" ?

cyrus-sasl-devel-2.1.15-10

any ideas?

IMHO this package should not install md5.h in that system location; more recent versions of that package use /usr/include/sasl/md5.h instead (see for example cyrus-sasl-devel-2.1.22-8).

I don't know RHEL - maybe you can update the RPM?

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All this doesn't alter anything, you know. The world is still full of
stupid people. They don't use their brains. They don't seem  to  want
to think straight.                    - Terry Pratchett, _Soul Music_
#8 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 22 lines · Wolfgang Denk

In message <9A2E2F7A-D812-4818-

Quoted 4 lines · A728-3DB51306356A at kernel.crashing.org> you wrote:
Quoted 4 lines
Quoted 2 lines

Which Linux distro are you running?

RHEL WS 3

Oops.

Quoted 13 lines
Quoted 12 lines
Quoted 10 lines
Quoted 8 lines

/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'

Which package in your distro installs "/usr/include/md5.h" ?

cyrus-sasl-devel-2.1.15-10

Quoted 7 lines
Quoted 1 line

any ideas?

IMHO this package should not install md5.h in that system location; more recent versions of that package use /usr/include/sasl/md5.h instead (see for example cyrus-sasl-devel-2.1.22-8).

I don't know RHEL - maybe you can update the RPM?

Not that I'm aware of. Its a box run by our IT department so I have no ability to upgrade or modify things. It looks like RHEL4 has the same issue.

ld2047$ rpm -qf /usr/include/md5.h
cyrus-sasl-devel-2.1.19-5.EL4

Any ideas on how to work around this? Do we really intend to pick up the system md5.h or should we be getting the one from u-boot/include/ md5.h?

- k

#9 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 2 lines

I don't know RHEL - maybe you can update the RPM?

Not that I'm aware of. Its a box run by our IT department so I have no ability to upgrade or modify things. It looks like RHEL4 has the same issue.

ld2047$ rpm -qf /usr/include/md5.h
cyrus-sasl-devel-2.1.19-5.EL4

I see. I have to go back pretty far in time to find such a configuration:

	$ ls -l /usr/include/md5.h
	-rw-r--r--  1 root root 1572 Apr 24  2006 /usr/include/md5.h
	$ rpm -qf /usr/include/md5.h
	cyrus-sasl-devel-2.1.20-6
	$ cat /etc/issue
	Fedora Core release 4 (Stentz)

All more recent distros seem to have this fixed (and yes, cyrus-sasl-devel is installed in all of them):

	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 5 (Bordeaux)
	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 6 (Zod)
	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 7 (Moonshine)
	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 8 (Werewolf)
Quoted 3 lines

Any ideas on how to work around this? Do we really intend to pick up the system md5.h or should we be getting the one from u-boot/include/ md5.h?

We need the system md5.h, I think. We'll investigate.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Why should we subsidize intellectual curiosity?" - Ronald Reagan
#10 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 44 lines · Wolfgang Denk
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 2 lines

I don't know RHEL - maybe you can update the RPM?

Not that I'm aware of. Its a box run by our IT department so I have no ability to upgrade or modify things. It looks like RHEL4 has the same issue.

ld2047$ rpm -qf /usr/include/md5.h
cyrus-sasl-devel-2.1.19-5.EL4

I see. I have to go back pretty far in time to find such a configuration:

	$ ls -l /usr/include/md5.h
	-rw-r--r--  1 root root 1572 Apr 24  2006 /usr/include/md5.h
	$ rpm -qf /usr/include/md5.h
	cyrus-sasl-devel-2.1.20-6
	$ cat /etc/issue
	Fedora Core release 4 (Stentz)

All more recent distros seem to have this fixed (and yes, cyrus-sasl-devel is installed in all of them):

	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 5 (Bordeaux)
	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 6 (Zod)
	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 7 (Moonshine)
	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 8 (Werewolf)
Quoted 5 lines
Quoted 3 lines

Any ideas on how to work around this? Do we really intend to pick up the system md5.h or should we be getting the one from u-boot/include/ md5.h?

We need the system md5.h, I think. We'll investigate.

If I force things to use the md5.h in u-boot/include things seem to build. Here's the patch for the forcing:

common/image.c +2 -2
index f04826a..cf3c9f3 100644
@@ -53,7 +53,7 @@
 #endif
 
 #if defined(CONFIG_FIT)
-#include <md5.h>
+#include "../md5.h"
 #include <sha1.h>
 
 static int fit_check_ramdisk (const void *fit, int os_noffset,

@@ -70,7 +70,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 						int verify);
 #else
 #include "mkimage.h"
-#include <md5.h>
+#include "../include/md5.h"
 #include <time.h>
 #include <image.h>
 #endif /* !USE_HOSTCC*/
lib_generic/md5.c +1 -1
index a51da45..b99ccc4 100644
@@ -27,7 +27,7 @@
 
 #include <linux/types.h>
 #include <linux/string.h>
-#include <md5.h>
+#include "../include/md5.h"
 
 static void
 MD5Transform(__u32 buf[4], __u32 const in[16]);
author
#11 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 1 line · Kumar Gala

On Tue, 1 Apr 2008, Wolfgang Denk wrote:

[...]

Quoted 7 lines
Quoted 4 lines
Quoted 3 lines

Any ideas on how to work around this? Do we really intend to pick up the system md5.h or should we be getting the one from u-boot/include/ md5.h?

We need the system md5.h, I think. We'll investigate.

If I force things to use the md5.h in u-boot/include things seem to build. Here's the patch for the forcing:

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:

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).

Kumar - could you try the patch out and see if it helps your build issue?

Regards,
Bartlomiej

tools/Makefile +1 -1
index 8784a6d..93f74aa 100644
@@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
  #
  # Use native tools and options
  #
-CPPFLAGS   = -idirafter $(SRCTREE)/include \
+CPPFLAGS   = -I $(SRCTREE)/include \

		-idirafter $(OBJTREE)/include2 \
		-idirafter $(OBJTREE)/include \
		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC
#12 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 41 lines · Bartlomiej Sieka
Quoted 1 line · Kumar Gala

On Tue, 1 Apr 2008, Wolfgang Denk wrote:

[...]

Quoted 9 lines
Quoted 6 lines
Quoted 5 lines

Any ideas on how to work around this? Do we really intend to pick up
the system md5.h or should we be getting the one from u-boot/ include/
md5.h?

We need the system md5.h, I think. We'll investigate.

If I force things to use the md5.h in u-boot/include things seem to build.
Here's the patch for the forcing:

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:

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).

Kumar - could you try the patch out and see if it helps your build issue?

Regards,
Bartlomiej

tools/Makefile +0 -0
index 8784a6d..93f74aa 100644

tools/Makefile BINS := $(addprefix $(obj),$(BIN_FILES)) · line 123

Quoted 8 lines
tools/Makefile +1 -1
@@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
 #
 # Use native tools and options
 #
-CPPFLAGS   = -idirafter $(SRCTREE)/include \
+CPPFLAGS   = -I $(SRCTREE)/include \
 		-idirafter $(OBJTREE)/include2 \
 		-idirafter $(OBJTREE)/include \
 		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC

I get:

gcc -g -Wall -I /tmp/u-boot-85xx/include -idirafter /tmp/u-boot-85xx/ include2 -idirafter /tmp/u-boot-85xx/include -DTEXT_BASE=0xfff80000 - DUSE_HOSTCC -O -c -o image.o image.c
In file included from image.c:73:
/usr/include/md5.h:27: error: parse error before "UINT4" /usr/include/md5.h:30: error: parse error before '}' token /usr/include/md5.h:38: error: parse error before "PROTO_LIST" /usr/include/md5.h:39: error: parse error before "PROTO_LIST" /usr/include/md5.h:41: error: parse error before "PROTO_LIST" /usr/include/md5.h:43: error: parse error before "PROTO_LIST" image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5' make[1]: *** [image.o] Error 1
make[1]: Leaving directory `/tmp/u-boot-85xx/tools'
make: *** [tools] Error 2

- k

#13 lore raw

PATCH 1/1 Fix host tool build breakage, take two

In reply to Bartlomiej Sieka
Quoted 4 lines · 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.

Quoted 8 lines
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. And we should really make sure that U-Boot header files get used only iff there is no corresponding host header file, and in this case we should make sure that this is intentional.

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).

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9
#14 lore raw

RFC 1/1 Rename include/md5.h to u-boot-md5.h

Some systems have md5.h installed in /usr/include/. This isn't the desired file (we want the one in include/md5.h). This will avoid the conflict. This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>

---

This fixes the problem for me, at least...

 common/image.c       |    4 ++--
 include/u-boot-md5.h |   23 +++++++++++++++++++++++
 lib_generic/md5.c    |    2 +-
 3 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 include/u-boot-md5.h
common/image.c +2 -2
index f04826a..2ee49ef 100644
@@ -53,7 +53,7 @@
 #endif
 
 #if defined(CONFIG_FIT)
-#include <md5.h>
+#include <u-boot-md5.h>
 #include <sha1.h>
 
 static int fit_check_ramdisk (const void *fit, int os_noffset,

@@ -70,7 +70,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 						int verify);
 #else
 #include "mkimage.h"
-#include <md5.h>
+#include <u-boot-md5.h>
 #include <time.h>
 #include <image.h>
 #endif /* !USE_HOSTCC*/
include/u-boot-md5.h new file +23 -0
new file mode 100644
index 0000000..046d1ee
@@ -0,0 +1,23 @@
+/*
+ * This file was transplanted with slight modifications from Linux sources
+ * (fs/cifs/md5.h) into U-Boot by Bartlomiej Sieka <[email protected]>.
+ */
+
+#ifndef _MD5_H
+#define _MD5_H
+
+#include <linux/types.h>
+
+struct MD5Context {
+	__u32 buf[4];
+	__u32 bits[2];
+	unsigned char in[64];
+};
+
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at
+ * 'input'. 'output' must have enough space to hold 16 bytes.
+ */
+void md5 (unsigned char *input, int len, unsigned char output[16]);
+
+#endif /* _MD5_H */
lib_generic/md5.c +1 -1
index a51da45..3427172 100644
@@ -27,7 +27,7 @@
 
 #include <linux/types.h>
 #include <linux/string.h>
-#include <md5.h>
+#include <u-boot-md5.h>
 
 static void
 MD5Transform(__u32 buf[4], __u32 const in[16]);
Signature · 1 line
1.5.4.23.gef5b9
#15 lore raw

[U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h

Quoted 10 lines · Andy Fleming

Some systems have md5.h installed in /usr/include/. This isn't the desired
file (we want the one in include/md5.h). This will avoid the conflict.
This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>

---

This fixes the problem for me, at least...

Which is on a RHEL3 box?

(cat /etc/redhat-release)

- k

#16 lore raw

[U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h

Quoted 1 line

cat /etc/redhat-release

Red Hat Enterprise Linux WS release 3 (Taroon Update 6)

Quoted 31 lines · Kumar Gala
Quoted 10 lines · Andy Fleming

Some systems have md5.h installed in /usr/include/. This isn't the desired
file (we want the one in include/md5.h). This will avoid the conflict.
This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>

---

This fixes the problem for me, at least...

Which is on a RHEL3 box?

(cat /etc/redhat-release)

- k

-------------------------------------------------------------------------
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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Acked-by on v1 1/1
#17 lore raw

[U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h

In reply to Andy Fleming
Quoted 5 lines · Andy Fleming

Some systems have md5.h installed in /usr/include/. This isn't the desired file (we want the one in include/md5.h). This will avoid the conflict. This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>
Acked-by Timur Tabi <[email protected]>

This fixes a build break for me. Please apply.

Signature · 2 lines
Timur Tabi
Linux kernel developer at Freescale
#18 lore raw

[U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h

In reply to Andy Fleming
Quoted 20 lines · Andy Fleming

Some systems have md5.h installed in /usr/include/. This isn't the desired file (we want the one in include/md5.h). This will avoid the conflict. This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>

---

This fixes the problem for me, at least...

 common/image.c       |    4 ++--
 include/u-boot-md5.h |   23 +++++++++++++++++++++++
 lib_generic/md5.c    |    2 +-
 3 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 include/u-boot-md5.h
common/image.c +0 -0
index f04826a..2ee49ef 100644

common/image.c line 56

Quoted 5 lines
common/image.c +1 -1
@@ -53,7 +53,7 @@
 #endif
 
 #if defined(CONFIG_FIT)
-#include <md5.h>
+#include <u-boot-md5.h>

Could we create an u-boot dirent like do int linux like #include <u-boot/md5.h>

Best Regards
J.

#19 lore raw

[U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h

In reply to Andy Fleming
Quoted 7 lines · In message <[email protected]> you wrote:

Some systems have md5.h installed in /usr/include/. This isn't the desired file (we want the one in include/md5.h). This will avoid the conflict. This fixes the host tools building problem

Signed-off-by Andy Fleming <[email protected]>

---

Quoted 7 lines

This fixes the problem for me, at least...

 common/image.c       |    4 ++--
 include/u-boot-md5.h |   23 +++++++++++++++++++++++
 lib_generic/md5.c    |    2 +-
 3 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 include/u-boot-md5.h

Applied with slight modification: I decided to use a separate directory, i. e. include/u-boot/md5.h

Thanks a lot!

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The rule on staying alive as a program manager is to give 'em a  num-
ber or give 'em a date, but never give 'em both at once.
author
#20 lore raw

PATCH 1/1 Fix host tool build breakage, take two

In reply to Wolfgang Denk
Quoted 17 lines · Wolfgang Denk
Quoted 3 lines · 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.

Quoted 8 lines
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).

Quoted 5 lines

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.

Quoted 18 lines

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.

Quoted 1 line

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

#21 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 4 lines · In message <[email protected]> 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.

Quoted 7 lines
Quoted 5 lines

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.

2) seems to be more robust, though -- 3) works until someone installs a

2 is not robust. It fails easily as soon as you move or rename files, as son as you miss to create one of trhe needed directories when building out of tree, etc.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I had the rare misfortune of being one of the first people to try and
implement a PL/1 compiler.                             -- T. Cheatham
#22 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 6 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> 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.

Quoted 8 lines

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.

Quoted 11 lines
Quoted 7 lines
Quoted 5 lines

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.

2) seems to be more robust, though -- 3) works until someone installs a

2 is not robust. It fails easily as soon as you move or rename files, as son as you miss to create one of trhe needed directories when building out of tree, etc.

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.

-Scott

#23 lore raw

PATCH 1/1 Fix host tool build breakage, take two

Quoted 12 lines · Scott Wood
Quoted 11 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> 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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 4 lines

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

#24 lore raw

PATCH 1/1 Fix host tool build breakage, take two

In reply to Scott Wood
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 4 lines

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.

Correct, and that's whY I agree that renaming it to make name collisions at least unlikely is a good thing.

Quoted 3 lines

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.

Agreed, too.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Give a man a fish, and you feed him for a day. Teach a man  to  fish,
and he'll invite himself over for dinner.             - Calvin Keegan