[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Bartlomiej Sieka]

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

Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
---
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?

diff --git a/include/fdt.h b/include/fdt.h
index 39beada..48ccfd9 100644
--- a/include/fdt.h
+++ b/include/fdt.h
@@ -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 */
diff --git a/include/libfdt_env.h b/include/libfdt_env.h
index 98c522a..ab5c301 100644
--- a/include/libfdt_env.h
+++ b/include/libfdt_env.h
@@ -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)

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Markus Klotzbücher]

Hi Bartlomiej,

Bartlomiej Sieka <tur@semihalf.com> writes:

> Revert commit 87c8431f and fix build breakage so that the build continues
> to work on FC systems.
>
> Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>
> ---
> 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 <mk@denx.de>

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Haavard Skinnemoen]

On Thu, 27 Mar 2008 15:06:40 +0100
Bartlomiej Sieka <tur@semihalf.com> wrote:

> Revert commit 87c8431f and fix build breakage so that the build continues
> to work on FC systems.
> 
> Signed-off-by: Bartlomiej Sieka <tur@semihalf.com>

Tested-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>

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

Haavard

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <EB0C2999-8BB8-4F0E-B3E4-DE4C28EA97D9@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?

> /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

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

On Mar 28, 2008, at 9:45 AM, Wolfgang Denk wrote:
> In message <EB0C2999-8BB8-4F0E-B3E4- 
> 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

>> /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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

On Mar 28, 2008, at 10:44 AM, Kumar Gala wrote:
>
> On Mar 28, 2008, at 9:45 AM, Wolfgang Denk wrote:
>> In message <EB0C2999-8BB8-4F0E-B3E4-
>> 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
>
>>> /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

any ideas?

- k

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <9A2E2F7A-D812-4818-A728-3DB51306356A@kernel.crashing.org> you wrote:
> 
> >> Which Linux distro are you running?
> >
> > RHEL WS 3

Oops. 

> >>> /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
> 
> 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

-- 
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_

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

On Mar 31, 2008, at 3:23 PM, Wolfgang Denk wrote:
> In message <9A2E2F7A-D812-4818- 
> A728-3DB51306356A at kernel.crashing.org> you wrote:
>>
>>>> Which Linux distro are you running?
>>>
>>> RHEL WS 3
>
> Oops.
>
>>>>> /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
>>
>> 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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <5D708345-1CF3-46FA-B9D2-689C52625177@kernel.crashing.org> you wrote:
> 
> > 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)

> 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

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

On Tue, 1 Apr 2008, Wolfgang Denk wrote:

> In message <5D708345-1CF3-46FA-B9D2-689C52625177@kernel.crashing.org> you wrote:
> >
> > > 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)
>
> > 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:

diff --git a/common/image.c b/common/image.c
index f04826a..cf3c9f3 100644
--- a/common/image.c
+++ b/common/image.c
@@ -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*/
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index a51da45..b99ccc4 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -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]);

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Bartlomiej Sieka]

Kumar Gala wrote:
> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
[...]
>>> 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

diff --git a/tools/Makefile b/tools/Makefile
index 8784a6d..93f74aa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Kumar Gala]

On Apr 2, 2008, at 10:59 AM, Bartlomiej Sieka wrote:
> Kumar Gala wrote:
>> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
> [...]
>>>> 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
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 8784a6d..93f74aa 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <47F3AD74.4000900@semihalf.com> 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.

> 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

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

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

[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 <afleming@freescale.com>
---

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

diff --git a/common/image.c b/common/image.c
index f04826a..2ee49ef 100644
--- a/common/image.c
+++ b/common/image.c
@@ -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*/
diff --git a/include/u-boot-md5.h b/include/u-boot-md5.h
new file mode 100644
index 0000000..046d1ee
--- /dev/null
+++ b/include/u-boot-md5.h
@@ -0,0 +1,23 @@
+/*
+ * This file was transplanted with slight modifications from Linux sources
+ * (fs/cifs/md5.h) into U-Boot by Bartlomiej Sieka <tur@semihalf.com>.
+ */
+
+#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 */
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index a51da45..3427172 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -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]);
-- 
1.5.4.23.gef5b9

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

[Kumar Gala]

On Apr 2, 2008, at 4:19 PM, Andy Fleming 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 <afleming@freescale.com>
> ---
>
> This fixes the problem for me, at least...

Which is on a RHEL3 box?

(cat /etc/redhat-release)

- k

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

[Andy Fleming]

> cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 6)


On Wed, Apr 2, 2008 at 4:50 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>  On Apr 2, 2008, at 4:19 PM, Andy Fleming 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 <afleming@freescale.com>
>  > ---
>  >
>  > 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
>

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

[Timur Tabi]

Andy Fleming 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 <afleming@freescale.com>

Acked-by: Timur Tabi <timur@freescale.com>

This fixes a build break for me.  Please apply.

-- 
Timur Tabi
Linux kernel developer at Freescale

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:19 Wed 02 Apr     , Andy Fleming 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 <afleming@freescale.com>
> ---
> 
> 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
> 
> diff --git a/common/image.c b/common/image.c
> index f04826a..2ee49ef 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -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.

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

[Wolfgang Denk]

In message <1207171147-3228-1-git-send-email-afleming@freescale.com> 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 <afleming@freescale.com>
> ---
> 
> 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

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Bartlomiej Sieka]

Wolfgang Denk wrote:
> In message <47F3AD74.4000900@semihalf.com> 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.
> 
>> 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.

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.

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

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <47F506DB.6010506@semihalf.com> 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.

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

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Scott Wood]

On Thu, Apr 03, 2008 at 08:26:23PM +0200, Wolfgang Denk wrote:
> In message <47F506DB.6010506@semihalf.com> 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.

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.

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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Andy Fleming]

On Thu, Apr 3, 2008 at 1:36 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Apr 03, 2008 at 08:26:23PM +0200, Wolfgang Denk wrote:
>  > In message <47F506DB.6010506@semihalf.com> 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.
>
>  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.


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

[U-Boot-Users] [PATCH] Fix host tool build breakage, take two

[Wolfgang Denk]

In message <20080403183627.GA9846@ld0162-tx32.am.freescale.net> you wrote:
>
> > 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.

> 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

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