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

2008-03-27 14:06 UTC #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)

Markus Klotzbücher

2008-03-27 14:44 UTC #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

Haavard Skinnemoen

2008-03-27 14:44 UTC #2 lore raw

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

In reply to Bartlomiej Sieka

Quoted 4 lines · On Thu, 27 Mar 2008 15:06:40 +0100 Bartlomiej Sieka <[email protected]> wrote:

Revert commit 87c8431f and fix build breakage so that the build continues to work on FC systems.
Signed-off-by Bartlomiej Sieka <[email protected]>

Tested-by Haavard Skinnemoen <[email protected]>

Using Debian lenny, gcc version 4.2.3 (Debian 4.2.3-2)

Haavard

Kumar Gala

2008-03-28 13:19 UTC #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

Wolfgang Denk

2008-03-28 14:45 UTC #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.

Kumar Gala

2008-03-28 15:44 UTC #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

Kumar Gala

2008-03-31 16:50 UTC #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

Wolfgang Denk

2008-03-31 20:23 UTC #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_

Kumar Gala

2008-04-01 15:04 UTC #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

Wolfgang Denk

2008-04-01 20:41 UTC #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

Kumar Gala

2008-04-02 14:55 UTC #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]);

Bartlomiej Sieka

author

2008-04-02 15:59 UTC #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

Kumar Gala

2008-04-02 17:24 UTC #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

Wolfgang Denk

2008-04-02 18:57 UTC #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

Andy Fleming

2008-04-02 21:19 UTC #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

Kumar Gala

2008-04-02 21:50 UTC #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

Andy Fleming

2008-04-02 22:06 UTC #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

Timur Tabi

Acked-by on v1 1/1

2008-04-03 21:49 UTC #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

Jean-Christophe PLAGNIOL-VILLARD

2008-04-06 11:18 UTC #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.

Wolfgang Denk

2008-04-14 01:09 UTC #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.

Bartlomiej Sieka

author

2008-04-03 16:33 UTC #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

Wolfgang Denk

2008-04-03 18:26 UTC #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

Scott Wood

2008-04-03 18:36 UTC #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

Andy Fleming

2008-04-03 20:09 UTC #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

Wolfgang Denk

2008-04-03 22:04 UTC #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