[U-Boot-Users] [PATCH] 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 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)
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@denx.de
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
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
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
On Mar 28, 2008, at 9:45 AM, Wolfgang Denk wrote:
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?
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
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@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
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
On Mar 31, 2008, at 3:23 PM, Wolfgang Denk wrote:
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?
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
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
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]);
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
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
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
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]);
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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.
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.
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
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:
- 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.
- 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.
- 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
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.
- 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.
- 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.
- 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
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.
- 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.
- 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.
- 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
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
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
participants (10)
-
Andy Fleming -
Andy Fleming -
Bartlomiej Sieka -
Haavard Skinnemoen -
Jean-Christophe PLAGNIOL-VILLARD -
Kumar Gala -
Markus Klotzbücher -
Scott Wood -
Timur Tabi -
Wolfgang Denk