| Message ID | CACRpkdaqvK3730mB67C8Bmpfm6fLHb1Tz-Bzr=Lhxn1bFw2i3g@mail.gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: > I do this, first I apply the patches I sent for Integrator support, then > I apply this patch to test with network support: no changes at all should be necessary to include/configs/. build the tools in an unconfigured tree to avoid any of that cruft. $ git clean -x -d $ make tools $ size tools/gen_eth_addr.o -mike
On Tue, Jul 12, 2011 at 5:49 PM, Mike Frysinger <vapier@gentoo.org> wrote: > On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: >> I do this, first I apply the patches I sent for Integrator support, then >> I apply this patch to test with network support: > > no changes at all should be necessary to include/configs/. build the > tools in an unconfigured tree to avoid any of that cruft. > > $ git clean -x -d > $ make tools > $ size tools/gen_eth_addr.o If you do this gen_eth_addr.o isn't even built, since it is only built if you first configure a board with CONFIG_CMD_NET of some kind. $ git clean -x -d $ make tools (... some clean build logs ...) $ size tools/gen_eth_addr.o size: 'tools/gen_eth_addr.o': No such file If I do the minimal test case like this: $ make tools CONFIG_CMD_NET=y I indeed get the same error again: make -C tools all make[1]: Entering directory `/home/linus/u-boot/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o gen_eth_addr.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [gen_eth_addr] Error 1 make[1]: Leaving directory `/home/linus/u-boot/tools' make: *** [tools] Error 2 So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. Thanks, Linus Walleij
On Tue, Jul 12, 2011 at 14:48, Linus Walleij wrote: > On Tue, Jul 12, 2011 at 5:49 PM, Mike Frysinger wrote: >> On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: >>> I do this, first I apply the patches I sent for Integrator support, then >>> I apply this patch to test with network support: >> >> no changes at all should be necessary to include/configs/. build the >> tools in an unconfigured tree to avoid any of that cruft. >> >> $ git clean -x -d >> $ make tools >> $ size tools/gen_eth_addr.o > > If you do this gen_eth_addr.o isn't even built, since it is only built > if you first configure a board with CONFIG_CMD_NET of some kind. not really. either use `make tools-all`, or `make CONFIG_CMD_NET=y tools`. but you figured that out already ... > I indeed get the same error again: > make -C tools all > make[1]: Entering directory `/home/linus/u-boot/tools' > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 > -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt > -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC > -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c > -c > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 > -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt > -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC > -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o > gen_eth_addr.o: file not recognized: File truncated > collect2: ld returned 1 exit status > make[1]: *** [gen_eth_addr] Error 1 > make[1]: Leaving directory `/home/linus/u-boot/tools' > make: *** [tools] Error 2 > > So yes, I can positively repeat this on a clean tree. It's still -pendantic that > is the culprit, if I copy the above and run manually without -pedantic > it compiles fine. are you using ccache ? -mike
On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger <vapier@gentoo.org> wrote: > [Me] >> So yes, I can positively repeat this on a clean tree. It's still -pendantic that >> is the culprit, if I copy the above and run manually without -pedantic >> it compiles fine. > > are you using ccache ? Yes :-P I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. Thanks Mike! I wonder if we could autodetect this so noone else runs into it? Linus Walleij
On Tue, Jul 12, 2011 at 14:59, Linus Walleij wrote: > On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger wrote: >> [Me] >>> So yes, I can positively repeat this on a clean tree. It's still -pendantic that >>> is the culprit, if I copy the above and run manually without -pedantic >>> it compiles fine. >> >> are you using ccache ? > > Yes :-P > > I didn't think so, but nowadays it's apparently in the Fedora development tools > groupinstall. Removing the package and spawning a new shell indeed solves > the problem, like I guess deleting the ccache database would. > > Thanks Mike! > > I wonder if we could autodetect this so noone else runs into it? not really. sounds like ccache db corruption (lose power recently?), and as with any corruption, "detecting" it in arbitrary build systems isnt exactly a trivial task. if you get back a valid ELF object, but not the right one, how is u-boot to know ? i'd `ccache -C` and forget about the whole thing :P -mike
Dear Linus Walleij, In message <CACRpkdaqvK3730mB67C8Bmpfm6fLHb1Tz-Bzr=Lhxn1bFw2i3g@mail.gmail.com> you wrote: > > Yes I'm reluctant about the whole thing, doesn't say from the patch it > was indeed intended as a discussion item... You should have marked it as "RFC" in the subject, then. > Then this happens on my side: > > make -C tools all > make[1]: Entering directory `/home/linus/u-boot/tools' > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/linus/u-boot/include -idirafter > /home/linus/u-boot/build/include2 -idirafter > /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I > /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 > -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o > /home/linus/u-boot/build/tools/gen_eth_addr.o gen_eth_addr.c -c > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter > /home/linus/u-boot/include -idirafter > /home/linus/u-boot/build/include2 -idirafter > /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I > /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 > -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o > /home/linus/u-boot/build/tools/gen_eth_addr > /home/linus/u-boot/build/tools/gen_eth_addr.o > /home/linus/u-boot/build/tools/gen_eth_addr.o: file not recognized: > File truncated > collect2: ld returned 1 exit status > make[1]: *** [/home/linus/u-boot/build/tools/gen_eth_addr] Error 1 > make[1]: Leaving directory `/home/linus/u-boot/tools' > make: *** [tools] Error 2 > > Which is because: > ls -al build/tools/gen_eth_addr.o > -rw-rw-r--. 1 linus linus 0 Jul 12 17:16 build/tools/gen_eth_addr.o This is what I see: Short: -> ./MAKEALL ap920t Configuring for ap920t board... Variant: Core module CM920T with core arm920t pci.c: In function 'pci_init_board': pci.c:392: warning: implicit declaration of function 'pciauto_config_init' text data bss dec hex filename 162650 3236 36260 202146 315a2 ./u-boot --------------------- SUMMARY ---------------------------- Boards compiled: 1 Boards with warnings or errors: 1 ( ap920t ) ---------------------------------------------------------- Long: ... make -C tools all make[1]: Entering directory `/home/wd/git/u-boot/work/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o strip gen_eth_addr gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o img2srec.o img2srec.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x01000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o img2srec img2srec.o strip img2srec ... > Not many hints here though :-( Something in your host system appears to be broken. I've tested both on 32 bit (gcc-4.6.0-9.fc15.i686) and 64 bit (gcc-4.6.0-9.fc15.x86_64) systems, without seeing any such problems. Sorry... Best regards, Wolfgang Denk
Dear Linus Walleij, In message <CACRpkdaDsMRw3Uu6Q7_MaBsb-WpaEy-WMkYf7Q0wAxNby126Fw@mail.gmail.com> you wrote: > On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger <vapier@gentoo.org> wrote: > > [Me] > >> So yes, I can positively repeat this on a clean tree. It's still -pendantic that > >> is the culprit, if I copy the above and run manually without -pedantic > >> it compiles fine. > > > > are you using ccache ? > > Yes :-P > > I didn't think so, but nowadays it's apparently in the Fedora development tools > groupinstall. Removing the package and spawning a new shell indeed solves > the problem, like I guess deleting the ccache database would. I'm using ccache as well, and always did. Never saw such an issue before. Did you have any I/O errors (like corrupt data) on your system lately? Best regards, Wolfgang Denk
On Tue, Jul 12, 2011 at 16:05, Wolfgang Denk wrote: > Linus Walleij wrote: >> On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger wrote: >> > [Me] >> >> So yes, I can positively repeat this on a clean tree. It's still -pendantic that >> >> is the culprit, if I copy the above and run manually without -pedantic >> >> it compiles fine. >> > >> > are you using ccache ? >> >> Yes :-P >> >> I didn't think so, but nowadays it's apparently in the Fedora development tools >> groupinstall. Removing the package and spawning a new shell indeed solves >> the problem, like I guess deleting the ccache database would. > > I'm using ccache as well, and always did. Never saw such an issue > before. > > Did you have any I/O errors (like corrupt data) on your system lately? with Gentoo, we've often seen unexpected reboots (power loss / oom / oops / etc...) result in zero byte files being left in the cache. comes up semi-frequently for us since so many people are using ccache and building from source. the zero byte aspect makes sense when using ext4 due to the fs design (metadata gets committed, but contents are in transit and lost). perhaps ccache itself should grow a 0 byte file check. i cant imagine any valid compiled object being 0 bytes ... -mike
On Tue, Jul 12, 2011 at 10:05 PM, Wolfgang Denk <wd@denx.de> wrote: >> Yes I'm reluctant about the whole thing, doesn't say from the patch it >> was indeed intended as a discussion item... > >You should have marked it as "RFC" in the subject, then. I forgot, mea culpa. >> I didn't think so, but nowadays it's apparently in the Fedora development tools >> groupinstall. Removing the package and spawning a new shell indeed solves >> the problem, like I guess deleting the ccache database would. > > I'm using ccache as well, and always did. Never saw such an issue > before. > > Did you have any I/O errors (like corrupt data) on your system lately? Yep it's a laptop, it boots from a USB drive, sometimes I even drop the drive and disconnect it in transit so data corruption is happening every day. I removed ccache since I don't trust it anymore, sorry about the fuzz. Thanks Wolfgang, Linus Walleij
diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index 26eac8b..39c84b5 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -80,17 +80,7 @@ /* * Command line configuration. */ - - -#define CONFIG_CMD_IMI -#define CONFIG_CMD_BDI -#define CONFIG_CMD_BOOTD -#define CONFIG_CMD_MEMORY -#define CONFIG_CMD_FLASH -#define CONFIG_CMD_IMLS -#define CONFIG_CMD_LOADB -#define CONFIG_CMD_LOADS - +#include <config_cmd_default.h> #define CONFIG_BOOTDELAY 2 #define CONFIG_BOOTARGS "root=/dev/mtdblock0 mem=32M console=ttyAM0