[U-Boot] buildman errors
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p +In file included from ../include/common.h:86, + from ../lib/asm-offsets.c:15: +../include/part.h:13: error: redefinition of typedef ‘block_dev_desc_t’ +../include/ide.h:44: error: previous declaration of ‘block_dev_desc_t’ was here +make[2]: *** [lib/asm-offsets.s] Error 1 +make[1]: *** [prepare0] Error 2 +make: *** [sub-make] Error 2 +../tools/mxsboot.c: In function ‘mx28_create_sd_image’: +../tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ +/tmp/ccTLvksq.o: In function `main': +mxsboot.c:(.text+0x6d8): undefined reference to `htole32' +mxsboot.c:(.text+0x6e7): undefined reference to `htole32' +mxsboot.c:(.text+0x6f6): undefined reference to `htole32' +mxsboot.c:(.text+0x705): undefined reference to `htole32' +mxsboot.c:(.text+0x711): undefined reference to `htole32' +/tmp/ccTLvksq.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +collect2: ld returned 1 exit status +make[2]: *** [tools/mxsboot] Error 1 +make[1]: *** [tools] Error 2 +In file included from ../include/common.h:86:0, +../include/part.h:13:31: error: redefinition of typedef 'block_dev_desc_t' +../include/ide.h:44:31: note: previous declaration of 'block_dev_desc_t' was here +board/renesas/sh7753evb/built-in.o: In function `init_gether_mdio': +build/../board/renesas/sh7753evb/sh7753evb.c:94: undefined reference to `PMB_ADDR_BASE' +build/../board/renesas/sh7753evb/sh7753evb.c:94: undefined reference to `PMB_DATA_BASE' +build/../board/renesas/sh7753evb/sh7753evb.c:94: undefined reference to `mk_pmb_addr_val' +build/../board/renesas/sh7753evb/sh7753evb.c:94: undefined reference to `mk_pmb_data_val' +make[1]: *** [u-boot] Error 1 +/tmp/cc4yyPwX.o: In function `main': +/tmp/cc4yyPwX.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +../include/part.h:13: error: redefinition of typedef 'block_dev_desc_t' +../include/ide.h:44: note: previous declaration of 'block_dev_desc_t' was here +/tmp/cc2IW0SD.o: In function `main': +/tmp/cc2IW0SD.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +../include/ide.h:44: error: previous declaration of 'block_dev_desc_t' was here +/tmp/ccbcq0iG.o: In function `main': +/tmp/ccbcq0iG.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccMo5qYk.o: In function `main': +/tmp/ccMo5qYk.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow + (((base + size - 1) >> CSBNDS_EA_SHIFT) & + ^ +../board/tqc/tqm834x/tqm834x.c:80:2: note: containing loop + for(cs = 0; cs < 4; ++cs) { + ^ +/tmp/ccgFlFwP.o: In function `main': +/tmp/ccgFlFwP.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +In file included from ../include/linux/byteorder/big_endian.h:14:0, + from ../arch/powerpc/include/asm/byteorder.h:82, + from ../arch/powerpc/include/asm/bitops.h:8, + from ../include/linux/bitops.h:123, + from ../include/common.h:20, + from ../drivers/net/eepro100.c:8: + return le16_to_cpu (*(volatile u16 *) (addr + dev->iobase)); + ^ +../include/linux/byteorder/swab.h:81:31: note: in definition of macro '__swab16' + (__builtin_constant_p((__u16)(x)) ? \ + ^ +../include/linux/byteorder/generic.h:92:21: note: in expansion of macro '__le16_to_cpu' + #define le16_to_cpu __le16_to_cpu + ^ +../drivers/net/eepro100.c:243:9: note: in expansion of macro 'le16_to_cpu' + ^ +../include/linux/byteorder/swab.h:23:13: note: in definition of macro '___swab16' + (((__u16)(x) & (__u16)0x00ffU) << 8) | \ + ^ +../include/linux/byteorder/big_endian.h:37:26: note: in expansion of macro '__swab16' + #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) + ^ +../include/linux/byteorder/swab.h:24:13: note: in definition of macro '___swab16' + (((__u16)(x) & (__u16)0xff00U) >> 8) )) +../include/linux/byteorder/swab.h:83:13: note: in definition of macro '__swab16' + __fswab16((x))) + *(volatile u16 *) ((addr + dev->iobase)) = cpu_to_le16 (command); + ^ + *(volatile u32 *) ((addr + dev->iobase)) = cpu_to_le32 (command); + return le32_to_cpu (*(volatile u32 *) (addr + dev->iobase)); +../include/linux/byteorder/swab.h:85:31: note: in definition of macro '__swab32' + (__builtin_constant_p((__u32)(x)) ? \ +../include/linux/byteorder/generic.h:90:21: note: in expansion of macro '__le32_to_cpu' + #define le32_to_cpu __le32_to_cpu +../drivers/net/eepro100.c:259:9: note: in expansion of macro 'le32_to_cpu' +../include/linux/byteorder/swab.h:27:13: note: in definition of macro '___swab32' + (((__u32)(x) & (__u32)0x000000ffUL) << 24) | \ +../include/linux/byteorder/big_endian.h:35:26: note: in expansion of macro '__swab32' + #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) +../include/linux/byteorder/swab.h:28:13: note: in definition of macro '___swab32' + (((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \ +../include/linux/byteorder/swab.h:29:13: note: in definition of macro '___swab32' + (((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \ +../include/linux/byteorder/swab.h:30:13: note: in definition of macro '___swab32' + (((__u32)(x) & (__u32)0xff000000UL) >> 24) )) +../include/linux/byteorder/swab.h:87:13: note: in definition of macro '__swab32' + __fswab32((x))) +cc1: error: -Werror=date-time: no option -Wdate-time +/bin/sh: arc-elf32-tcf-ld: command not found +sh: -c: line 0: syntax error near unexpected token `(' +sh: -c: line 0: `arc-elf32-gcc -Wp,-MD,lib/.asm-offsets.s.d -nostdinc -isystem /BinMeng/toolchains/pre-built/arc-elf32/bin/../lib/gcc/arc-elf32/4.8.4/include -Iinclude -I../include -I../arch/arc/include -include ../include/linux/kconfig.h -I../. -I. -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -mbig-endian -marc700 -mlock -mswape -ffixed-r25 -D__ARC__ -gdwarf-2 -pipe -DDO_DEPS_ONLY -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets) -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -fverbose-asm -S -o lib/asm-offsets.s ../lib/asm-offsets.c' +fixdep: error opening depfile: lib/.asm-offsets.s.d: No such file or directory +make[2]: *** [lib/asm-offsets.s] Error 2 +/tmp/ccSqHFer.o: In function `main': +/tmp/ccSqHFer.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccO9ldSm.o: In function `main': +/tmp/ccO9ldSm.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +sh: -c: line 0: `arc-elf32-gcc -Wp,-MD,lib/.asm-offsets.s.d -nostdinc -isystem /BinMeng/toolchains/pre-built/arc-elf32/bin/../lib/gcc/arc-elf32/4.8.4/include -Iinclude -I../include -I../arch/arc/include -include ../include/linux/kconfig.h -I../. -I. -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -mlittle-endian -marc700 -mlock -mswape -ffixed-r25 -D__ARC__ -gdwarf-2 -pipe -DDO_DEPS_ONLY -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets) -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -fverbose-asm -S -o lib/asm-offsets.s ../lib/asm-offsets.c' +sh: -c: line 0: `arc-elf32-gcc -Wp,-MD,lib/.asm-offsets.s.d -nostdinc -isystem /BinMeng/toolchains/pre-built/arc-elf32/bin/../lib/gcc/arc-elf32/4.8.4/include -Iinclude -I../include -I../arch/arc/include -include ../include/linux/kconfig.h -I../. -I. -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -mlittle-endian -marchs -ffixed-r25 -D__ARC__ -gdwarf-2 -pipe -DDO_DEPS_ONLY -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets) -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -fverbose-asm -S -o lib/asm-offsets.s ../lib/asm-offsets.c' +/tmp/ccEZwIsK.o: In function `main': +/tmp/ccEZwIsK.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccUAhQzL.o: In function `main': +/tmp/ccUAhQzL.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccjy2Fh4.o: In function `main': +/tmp/ccjy2Fh4.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccJlvbna.o: In function `main': +/tmp/ccJlvbna.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +make[2]: *** [test_defconfig] Error 1 +make[1]: *** [test_defconfig] Error 2 w+../board/renesas/sh7753evb/sh7753evb.c: In function 'set_pmb_on_board_init': w+../board/renesas/sh7753evb/sh7753evb.c:139:2: warning: implicit declaration of function 'PMB_ADDR_BASE' [-Wimplicit-function-declaration] w+../board/renesas/sh7753evb/sh7753evb.c:140:2: warning: implicit declaration of function 'PMB_DATA_BASE' [-Wimplicit-function-declaration] w+../board/renesas/sh7753evb/sh7753evb.c:144:2: warning: implicit declaration of function 'mk_pmb_addr_val' [-Wimplicit-function-declaration] w+../board/renesas/sh7753evb/sh7753evb.c:145:2: warning: implicit declaration of function 'mk_pmb_data_val' [-Wimplicit-function-declaration] w+../board/tqc/tqm834x/tqm834x.c: In function 'initdram': w+../board/tqc/tqm834x/tqm834x.c:325:12: warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations] w+../drivers/net/eepro100.c: In function 'INW': w+../drivers/net/eepro100.c:243:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] w+../drivers/net/eepro100.c: In function 'OUTW': w+../drivers/net/eepro100.c:248:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] w+../drivers/net/eepro100.c: In function 'OUTL': w+../drivers/net/eepro100.c:253:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] w+../drivers/net/eepro100.c: In function 'INL': w+../drivers/net/eepro100.c:259:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] w+../drivers/net/rtl8169.c:310:2: warning: #warning cache-line size is larger than descriptor size [-Wcpp] 02: dm: pci: Move pci_bus_to_hose() to compatibility -/tmp/ccTLvksq.o: In function `main': -/tmp/ccTLvksq.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/cc4yyPwX.o: In function `main': -/tmp/cc4yyPwX.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/cc2IW0SD.o: In function `main': -/tmp/cc2IW0SD.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccbcq0iG.o: In function `main': -/tmp/ccbcq0iG.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccMo5qYk.o: In function `main': -/tmp/ccMo5qYk.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccgFlFwP.o: In function `main': -/tmp/ccgFlFwP.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccSqHFer.o: In function `main': -/tmp/ccSqHFer.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccO9ldSm.o: In function `main': -/tmp/ccO9ldSm.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccEZwIsK.o: In function `main': -/tmp/ccEZwIsK.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccUAhQzL.o: In function `main': -/tmp/ccUAhQzL.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccjy2Fh4.o: In function `main': -/tmp/ccjy2Fh4.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow -/tmp/ccJlvbna.o: In function `main': -/tmp/ccJlvbna.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccy6Xkgg.o: In function `main': +/tmp/ccy6Xkgg.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/cctNidX7.o: In function `main': +/tmp/cctNidX7.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/cccb35mL.o: In function `main': +/tmp/cccb35mL.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccmeZlXB.o: In function `main': +/tmp/ccmeZlXB.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/cc4NKIEp.o: In function `main': +/tmp/cc4NKIEp.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccphqrKu.o: In function `main': +/tmp/ccphqrKu.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccsOF6XN.o: In function `main': +/tmp/ccsOF6XN.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccNNdFlI.o: In function `main': +/tmp/ccNNdFlI.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccglBOl0.o: In function `main': +/tmp/ccglBOl0.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/cc02aBXn.o: In function `main': +/tmp/cc02aBXn.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccGjqBxy.o: In function `main': +/tmp/ccGjqBxy.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow +/tmp/ccEqMe7n.o: In function `main': +/tmp/ccEqMe7n.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow
Simon addressed the 'block_dev_desc_t' issue recently. Any plan to fix the others?
The most annoying one is the 'more undefined references to `htole32' follow' that it repeats for every commit build. Looks the 'htole32' was introduced in commit b5e7586a73d4eb7b0aa9c597f293a584a2a1800a "mxs: mxsboot: fix endianess for sd boot images"
Regards, Bin
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
nds32: + adp-ag101pI need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Best regards, Marek Vasut
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
Best regards, Stefano Babic
On Sun, Jan 24, 2016 at 06:01:44PM +0100, Stefano Babic wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
They're good for me too, BUT! I suspect it comes down to the openssl-dev requirement on the host side which I also have thought Marek noted at some point as a problem anyhow due to license issues maybe?
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Regards, Bin
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
Regards, Bin
On Monday, January 25, 2016 at 03:45:25 AM, Bin Meng wrote:
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP
blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur
bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4
aarch64: + test
avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4openrisc: + openrisc-generic
powerpc: + TQM834x katmai
arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plusmx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig
HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf
# # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot
tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
No, it's not. Try this patch:
--8<-- diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 3434c81..dd1027d 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -7,6 +7,7 @@ * SPDX-License-Identifier: GPL-2.0+ */
+#define _BSD_SOURCE #include <endian.h> #include <fcntl.h> #include <sys/stat.h> -->8--
It does the same thing the manpage endian(3) suggests. But I wonder if we shouldn't instead switch to something more portable ?
Hi Marek,
On Mon, Jan 25, 2016 at 10:52 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:45:25 AM, Bin Meng wrote:
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: > Hi, > > Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) > 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP > > blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur > > bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 > bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e > tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 > bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 > blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd > bf561-ezkit br4 > > aarch64: + test > > avr32: + atngw100mkii grasshopper atstk1002 atngw100 > > sh: + sh7753evb sh7785lcr_32bit sh7785lcr > > arc: + arcangel4-be axs101 axs103 tb100 arcangel4 > > openrisc: + openrisc-generic > > powerpc: + TQM834x katmai > > arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus > > mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino > mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig
HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf
# # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot
tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
No, it's not. Try this patch:
--8<-- diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 3434c81..dd1027d 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -7,6 +7,7 @@
- SPDX-License-Identifier: GPL-2.0+
*/
+#define _BSD_SOURCE #include <endian.h> #include <fcntl.h> #include <sys/stat.h> -->8--
No, it does not work with either gcc 4.1.2 or 4.7.2 :(
tools/mxsboot.c:10:1: warning: "_BSD_SOURCE" redefined In file included from /usr/include/stdint.h:26, from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from <command line>:1: /usr/include/features.h:162:1: warning: this is the location of the previous definition tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:561: warning: implicit declaration of function ‘htole32’ /tmp/ccGE1ile.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/ccGE1ile.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
It does the same thing the manpage endian(3) suggests. But I wonder if we shouldn't instead switch to something more portable ?
Regards, Bin
On Monday, January 25, 2016 at 03:58:38 AM, Bin Meng wrote:
Hi Marek,
On Mon, Jan 25, 2016 at 10:52 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:45:25 AM, Bin Meng wrote:
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote:
On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote: > On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: >> Hi, >> >> Summary of 71 commits for 1100 boards (24 threads, 1 job per >> thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP >> >> blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur >> >> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 >> bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e >> tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 >> bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 >> blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd >> bf561-ezkit br4 >> >> aarch64: + test >> >> avr32: + atngw100mkii grasshopper atstk1002 atngw100 >> >> sh: + sh7753evb sh7785lcr_32bit sh7785lcr >> >> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 >> >> openrisc: + openrisc-generic >> >> powerpc: + TQM834x katmai >> >> arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus >> >> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino >> mx28evk_auart_console
All of MXS is broken, why ? I don't recall any chances to MXS being done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig
HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf
# # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot
tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
No, it's not. Try this patch:
--8<-- diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 3434c81..dd1027d 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -7,6 +7,7 @@
- SPDX-License-Identifier: GPL-2.0+
*/
+#define _BSD_SOURCE
#include <endian.h> #include <fcntl.h> #include <sys/stat.h>
-->8--
No, it does not work with either gcc 4.1.2 or 4.7.2 :(
tools/mxsboot.c:10:1: warning: "_BSD_SOURCE" redefined In file included from /usr/include/stdint.h:26, from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from <command line>:1: /usr/include/features.h:162:1: warning: this is the location of the previous definition tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:561: warning: implicit declaration of function ‘htole32’ /tmp/ccGE1ile.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/ccGE1ile.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
It does the same thing the manpage endian(3) suggests. But I wonder if we shouldn't instead switch to something more portable ?
Ow, then a bit of googling shows this patch:
http://lists.denx.de/pipermail/u-boot/2014-October/192919.html
Hi Marek,
On Mon, Jan 25, 2016 at 11:01 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:58:38 AM, Bin Meng wrote:
Hi Marek,
On Mon, Jan 25, 2016 at 10:52 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:45:25 AM, Bin Meng wrote:
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote:
On 24/01/2016 17:41, Marek Vasut wrote: > On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote: >> On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: >>> Hi, >>> >>> Summary of 71 commits for 1100 boards (24 threads, 1 job per >>> thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP >>> >>> blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur >>> >>> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 >>> bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e >>> tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 >>> bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 >>> blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd >>> bf561-ezkit br4 >>> >>> aarch64: + test >>> >>> avr32: + atngw100mkii grasshopper atstk1002 atngw100 >>> >>> sh: + sh7753evb sh7785lcr_32bit sh7785lcr >>> >>> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 >>> >>> openrisc: + openrisc-generic >>> >>> powerpc: + TQM834x katmai >>> >>> arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus >>> >>> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino >>> mx28evk_auart_console > > All of MXS is broken, why ? I don't recall any chances to MXS being > done recently, so what happened ?
I confirm this - I have not seen any breakage (but I built today with an older gcc). Bing, can you output what you have seen for mxs boards ? They looks ok to me.
$ make m28evk_defconfig
HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf
# # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot
tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
No, it's not. Try this patch:
--8<-- diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 3434c81..dd1027d 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -7,6 +7,7 @@
- SPDX-License-Identifier: GPL-2.0+
*/
+#define _BSD_SOURCE
#include <endian.h> #include <fcntl.h> #include <sys/stat.h>
-->8--
No, it does not work with either gcc 4.1.2 or 4.7.2 :(
tools/mxsboot.c:10:1: warning: "_BSD_SOURCE" redefined In file included from /usr/include/stdint.h:26, from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from <command line>:1: /usr/include/features.h:162:1: warning: this is the location of the previous definition tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:561: warning: implicit declaration of function ‘htole32’ /tmp/ccGE1ile.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/ccGE1ile.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
It does the same thing the manpage endian(3) suggests. But I wonder if we shouldn't instead switch to something more portable ?
Ow, then a bit of googling shows this patch:
http://lists.denx.de/pipermail/u-boot/2014-October/192919.html
This works! I can prepare a patch if you like.
Regards, Bin
On Monday, January 25, 2016 at 04:12:37 AM, Bin Meng wrote:
Hi Marek,
Hi!
On Mon, Jan 25, 2016 at 11:01 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:58:38 AM, Bin Meng wrote:
Hi Marek,
On Mon, Jan 25, 2016 at 10:52 AM, Marek Vasut marex@denx.de wrote:
On Monday, January 25, 2016 at 03:45:25 AM, Bin Meng wrote:
On Mon, Jan 25, 2016 at 10:42 AM, Bin Meng bmeng.cn@gmail.com wrote:
On Mon, Jan 25, 2016 at 1:01 AM, Stefano Babic sbabic@denx.de wrote: > On 24/01/2016 17:41, Marek Vasut wrote: >> On Sunday, January 24, 2016 at 05:19:54 PM, Tom Rini wrote: >>> On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: >>>> Hi, >>>> >>>> Summary of 71 commits for 1100 boards (24 threads, 1 job per >>>> thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP >>>> >>>> blackfin: + bf561-acvilon cm-bf561 blackstamp >>>> bf537-minotaur >>>> >>>> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 >>>> bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 >>>> cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit >>>> ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit >>>> bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 >>>> bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 >>>> >>>> aarch64: + test >>>> >>>> avr32: + atngw100mkii grasshopper atstk1002 atngw100 >>>> >>>> sh: + sh7753evb sh7785lcr_32bit sh7785lcr >>>> >>>> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 >>>> >>>> openrisc: + openrisc-generic >>>> >>>> powerpc: + TQM834x katmai >>>> >>>> arm: + mx28evk mx28evk_nand xfi3 bg0900 >>>> sansa_fuze_plus >>>> >>>> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino >>>> mx28evk_auart_console >> >> All of MXS is broken, why ? I don't recall any chances to MXS >> being done recently, so what happened ? > > I confirm this - I have not seen any breakage (but I built today > with an older gcc). Bing, can you output what you have seen for > mxs boards ? They looks ok to me.
$ make m28evk_defconfig
HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf
# # configuration written to .config # $ make scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h UPD include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h UPD include/generated/generic-asm-offsets.h CC arch/arm/lib/asm-offsets.s CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h HOSTCC tools/bmp_logo HOSTCC tools/envcrc.o WRAP tools/lib/crc32.c HOSTCC tools/lib/crc32.o WRAP tools/common/env_embedded.c HOSTCC tools/common/env_embedded.o WRAP tools/lib/sha1.c HOSTCC tools/lib/sha1.o HOSTLD tools/envcrc HOSTCC tools/gen_eth_addr HOSTCC tools/img2srec HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o HOSTCC tools/atmelimage.o WRAP tools/common/bootm.c HOSTCC tools/common/bootm.o HOSTCC tools/default_image.o WRAP tools/lib/fdtdec_common.c HOSTCC tools/lib/fdtdec_common.o WRAP tools/lib/fdtdec.c HOSTCC tools/lib/fdtdec.o HOSTCC tools/fit_common.o HOSTCC tools/fit_image.o HOSTCC tools/gpimage.o HOSTCC tools/gpimage-common.o WRAP tools/common/image-fit.c HOSTCC tools/common/image-fit.o HOSTCC tools/image-host.o WRAP tools/common/image.c HOSTCC tools/common/image.o HOSTCC tools/imagetool.o HOSTCC tools/imximage.o HOSTCC tools/kwbimage.o WRAP tools/lib/md5.c HOSTCC tools/lib/md5.o HOSTCC tools/lpc32xximage.o HOSTCC tools/mxsimage.o HOSTCC tools/omapimage.o HOSTCC tools/pblimage.o HOSTCC tools/pbl_crc32.o WRAP tools/lib/rc4.c HOSTCC tools/lib/rc4.o HOSTCC tools/rkcommon.o HOSTCC tools/rkimage.o HOSTCC tools/rksd.o HOSTCC tools/rkspi.o HOSTCC tools/socfpgaimage.o WRAP tools/lib/sha256.c HOSTCC tools/lib/sha256.o WRAP tools/common/hash.c HOSTCC tools/common/hash.o HOSTCC tools/ublimage.o HOSTCC tools/zynqimage.o WRAP tools/lib/libfdt/fdt.c HOSTCC tools/lib/libfdt/fdt.o WRAP tools/lib/libfdt/fdt_ro.c HOSTCC tools/lib/libfdt/fdt_ro.o WRAP tools/lib/libfdt/fdt_rw.c HOSTCC tools/lib/libfdt/fdt_rw.o WRAP tools/lib/libfdt/fdt_strerror.c HOSTCC tools/lib/libfdt/fdt_strerror.o WRAP tools/lib/libfdt/fdt_wip.c HOSTCC tools/lib/libfdt/fdt_wip.o WRAP tools/lib/libfdt/fdt_region.c HOSTCC tools/lib/libfdt/fdt_region.o HOSTCC tools/dumpimage.o HOSTLD tools/dumpimage HOSTCC tools/mkimage.o HOSTLD tools/mkimage HOSTCC tools/mxsboot
tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:560: warning: implicit declaration of function ‘htole32’ /tmp/cchLIV6q.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/cchLIV6q.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
I am using gcc 4.1.2 as the HOSTCC.
Just switched to gcc 4.7.2 as the HOSTCC, still have this 'htole32' error. As Tom mentioned, this might be related to the host openssl-dev enviroment?
No, it's not. Try this patch:
--8<-- diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 3434c81..dd1027d 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -7,6 +7,7 @@
- SPDX-License-Identifier: GPL-2.0+
*/
+#define _BSD_SOURCE
#include <endian.h> #include <fcntl.h> #include <sys/stat.h>
-->8--
No, it does not work with either gcc 4.1.2 or 4.7.2 :(
tools/mxsboot.c:10:1: warning: "_BSD_SOURCE" redefined In file included from /usr/include/stdint.h:26,
from ././include/compiler.h:19, from ././include/libfdt_env.h:12, from <command line>:1:/usr/include/features.h:162:1: warning: this is the location of the previous definition tools/mxsboot.c: In function ‘mx28_create_sd_image’: tools/mxsboot.c:561: warning: implicit declaration of function ‘htole32’ /tmp/ccGE1ile.o: In function `main': mxsboot.c:(.text+0x6d8): undefined reference to `htole32' mxsboot.c:(.text+0x6e7): undefined reference to `htole32' mxsboot.c:(.text+0x6f6): undefined reference to `htole32' mxsboot.c:(.text+0x705): undefined reference to `htole32' mxsboot.c:(.text+0x711): undefined reference to `htole32' /tmp/ccGE1ile.o:mxsboot.c:(.text+0x71d): more undefined references to `htole32' follow collect2: ld returned 1 exit status make[1]: *** [tools/mxsboot] Error 1 make: *** [tools] Error 2
It does the same thing the manpage endian(3) suggests. But I wonder if we shouldn't instead switch to something more portable ?
Ow, then a bit of googling shows this patch:
http://lists.denx.de/pipermail/u-boot/2014-October/192919.html
This works! I can prepare a patch if you like.
Excellent, and it seems like the more permanent solution I had in mind too :) I guess you already have the patch ready anyway, so please submit it. Thanks!
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Regards, Bin
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Regards, Bin
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
Hi,
Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 aarch64: + test avr32: + atngw100mkii grasshopper atstk1002 atngw100 sh: + sh7753evb sh7785lcr_32bit sh7785lcr arc: + arcangel4-be axs101 axs103 tb100 arcangel4 openrisc: + openrisc-generic powerpc: + TQM834x katmai arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino mx28evk_auart_console nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
But this is nothing related to gcc 5.x. It should be something related to openssl. After I "dnf install openssl-devel", minnowmax can be built successfully without any error/warning.
Regards, Bin
On Tuesday, January 26, 2016 at 05:26:07 AM, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: > Hi, > > Summary of 71 commits for 1100 boards (24 threads, 1 job per > thread) 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP > > blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur > > bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 > bf527-ad7160-eval bf609-ezkit bf537-stamp bf527-ezkit-v2 > cm-bf537e tcm-bf518 cm-bf537u bf527-ezkit cm-bf533 bf533-ezkit > ibf-dsp561 bf537-pnav bf537-srv1 cm-bf548 bf538f-ezkit > bf548-ezkit bf525-ucr2 blackvme tcm-bf537 bf533-stamp dnp5370 > bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 > > aarch64: + test > > avr32: + atngw100mkii grasshopper atstk1002 atngw100 > > sh: + sh7753evb sh7785lcr_32bit sh7785lcr > > arc: + arcangel4-be axs101 axs103 tb100 arcangel4 > > openrisc: + openrisc-generic > > powerpc: + TQM834x katmai > > arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus > > mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino > mx28evk_auart_console > > nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
But this is nothing related to gcc 5.x. It should be something related to openssl. After I "dnf install openssl-devel", minnowmax can be built successfully without any error/warning.
Yeah, that's our standard openssl bug :-)
On Tue, Jan 26, 2016 at 12:26:07PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote:
On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote:
> Hi, > > Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) > 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP > blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur > bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval > bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u > bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 > cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 > bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 > aarch64: + test > avr32: + atngw100mkii grasshopper atstk1002 atngw100 > sh: + sh7753evb sh7785lcr_32bit sh7785lcr > arc: + arcangel4-be axs101 axs103 tb100 arcangel4 > openrisc: + openrisc-generic > powerpc: + TQM834x katmai > arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus > mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino > mx28evk_auart_console > nds32: + adp-ag101p
I need to finally fetch a few toolchains as I don't do avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc 5.x, can you look into it? :)
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
Are you using the stock configs? +(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) arch/x86/lib/built-in.o: In function `__wrap___udivdi3': +(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) build/../arch/x86/lib/gcc.c:25: undefined reference to `__normal___udivdi3'
Hi Tom,
On Tue, Jan 26, 2016 at 10:47 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 26, 2016 at 12:26:07PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote: > On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: > >> Hi, >> >> Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) >> 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP >> blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur >> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval >> bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u >> bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 >> cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 >> bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 >> aarch64: + test >> avr32: + atngw100mkii grasshopper atstk1002 atngw100 >> sh: + sh7753evb sh7785lcr_32bit sh7785lcr >> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 >> openrisc: + openrisc-generic >> powerpc: + TQM834x katmai >> arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus >> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino >> mx28evk_auart_console >> nds32: + adp-ag101p > > I need to finally fetch a few toolchains as I don't do > avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc > 5.x, can you look into it? :) >
Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
Are you using the stock configs?
Yes.
+(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) arch/x86/lib/built-in.o: In function `__wrap___udivdi3': +(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) build/../arch/x86/lib/gcc.c:25: undefined reference to `__normal___udivdi3'
Is your Fedora a 64-bit installation? And a 64-bit gcc compiler, right? I am using 32-bit Fedora with a 32-bit gcc. This is nothing related to gcc 5.x too. The same thing happens in gcc 4.x. If we want to use 64-bit gcc to build 32-bit U-Boot, gcc must ship with multilib support.
Regards, Bin
On Wed, Jan 27, 2016 at 09:55:02AM +0800, Bin Meng wrote:
Hi Tom,
On Tue, Jan 26, 2016 at 10:47 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 26, 2016 at 12:26:07PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote: > Hi Tom, > > On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote: > > On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: > > > >> Hi, > >> > >> Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) > >> 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP > >> blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur > >> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval > >> bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u > >> bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 > >> cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 > >> bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 > >> aarch64: + test > >> avr32: + atngw100mkii grasshopper atstk1002 atngw100 > >> sh: + sh7753evb sh7785lcr_32bit sh7785lcr > >> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 > >> openrisc: + openrisc-generic > >> powerpc: + TQM834x katmai > >> arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus > >> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino > >> mx28evk_auart_console > >> nds32: + adp-ag101p > > > > I need to finally fetch a few toolchains as I don't do > > avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc > > 5.x, can you look into it? :) > > > > Sure, I can look into x86. Which gcc 5.x toolchain are you using?
Pretty much any, I've seen it for a long time but not had time to poke at the libgcc "fun" that's involved here.
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
Are you using the stock configs?
Yes.
+(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) arch/x86/lib/built-in.o: In function `__wrap___udivdi3': +(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) build/../arch/x86/lib/gcc.c:25: undefined reference to `__normal___udivdi3'
Is your Fedora a 64-bit installation? And a 64-bit gcc compiler, right? I am using 32-bit Fedora with a 32-bit gcc. This is nothing related to gcc 5.x too. The same thing happens in gcc 4.x. If we want to use 64-bit gcc to build 32-bit U-Boot, gcc must ship with multilib support.
Ug, even with CONFIG_USE_PRIVATE_LIBGCC=y ?
Hi Tom,
On Wed, Jan 27, 2016 at 10:08 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 09:55:02AM +0800, Bin Meng wrote:
Hi Tom,
On Tue, Jan 26, 2016 at 10:47 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Jan 26, 2016 at 12:26:07PM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 10:12 PM, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 25, 2016 at 11:18:26AM +0800, Bin Meng wrote:
Hi Tom,
On Mon, Jan 25, 2016 at 11:05 AM, Tom Rini trini@konsulko.com wrote: > On Mon, Jan 25, 2016 at 10:34:16AM +0800, Bin Meng wrote: >> Hi Tom, >> >> On Mon, Jan 25, 2016 at 12:19 AM, Tom Rini trini@konsulko.com wrote: >> > On Sun, Jan 24, 2016 at 12:00:42PM +0800, Bin Meng wrote: >> > >> >> Hi, >> >> >> >> Summary of 71 commits for 1100 boards (24 threads, 1 job per thread) >> >> 01: iocon / bamboo: Drop CONFIG_SYS_LONGHELP >> >> blackfin: + bf561-acvilon cm-bf561 blackstamp bf537-minotaur >> >> bct-brettl2 cm-bf527 bf506f-ezkit ip04 bf527-sdp pr1 bf527-ad7160-eval >> >> bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u >> >> bf527-ezkit cm-bf533 bf533-ezkit ibf-dsp561 bf537-pnav bf537-srv1 >> >> cm-bf548 bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme tcm-bf537 >> >> bf533-stamp dnp5370 bf518f-ezbrd bf526-ezbrd bf561-ezkit br4 >> >> aarch64: + test >> >> avr32: + atngw100mkii grasshopper atstk1002 atngw100 >> >> sh: + sh7753evb sh7785lcr_32bit sh7785lcr >> >> arc: + arcangel4-be axs101 axs103 tb100 arcangel4 >> >> openrisc: + openrisc-generic >> >> powerpc: + TQM834x katmai >> >> arm: + mx28evk mx28evk_nand xfi3 bg0900 sansa_fuze_plus >> >> mx23evk m28evk sc_sps_1 mx28evk_spi apx4devkit mx23_olinuxino >> >> mx28evk_auart_console >> >> nds32: + adp-ag101p >> > >> > I need to finally fetch a few toolchains as I don't do >> > avr32/sh/openrisc/nds32 iirc. As a tangent, x86 is very broken with gcc >> > 5.x, can you look into it? :) >> > >> >> Sure, I can look into x86. Which gcc 5.x toolchain are you using? > > Pretty much any, I've seen it for a long time but not had time to poke > at the libgcc "fun" that's involved here. >
I mean if there is any prebuilt gcc 5.x for me to grab and test? Or do I need build one from gcc source?
Fedora has shipped with gcc 5.x for a release or two and Debian/unstable is how I get all of my gcc 5.x toolchains for build testing.
I installed a fresh Fedora 23 and got gcc 5.1.1 up and running. However I see _zero_ compiler warnings/errors using gcc 5.1.1 when building all of the 9 x86 boards.
The only thing I noticed, which is probably best matched to what you said "x86 is very broken with gcc 5.x", is:
HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:923:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. scripts/Makefile.host:111: recipe for target 'tools/aisimage.o' failed make[1]: *** [tools/aisimage.o] Error 1 Makefile:1196: recipe for target 'tools' failed make: *** [tools] Error 2
Are you using the stock configs?
Yes.
+(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) arch/x86/lib/built-in.o: In function `__wrap___udivdi3': +(galileo,crownbay,coreboot-x86,bayleybay,qemu-x86,chromebook_link,minnowmax,chromebox_panther) build/../arch/x86/lib/gcc.c:25: undefined reference to `__normal___udivdi3'
Is your Fedora a 64-bit installation? And a 64-bit gcc compiler, right? I am using 32-bit Fedora with a 32-bit gcc. This is nothing related to gcc 5.x too. The same thing happens in gcc 4.x. If we want to use 64-bit gcc to build 32-bit U-Boot, gcc must ship with multilib support.
Ug, even with CONFIG_USE_PRIVATE_LIBGCC=y ?
Yes. x86 build relies on gcc to provide a normal libgcc and adds some hacks on top of it (private).
Regards, Bin
participants (4)
-
Bin Meng -
Marek Vasut -
Stefano Babic -
Tom Rini