Hi, On Thu, 2008-07-31 at 00:35 -0700, Andrew Morton wrote: > On Thu, 31 Jul 2008 17:16:03 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > > Hi Dave, > > > > linux-next builds (sparc32 defconfig) have been failing for some time > > like this: > > > > .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses': > > : relocation truncated to fit: R_SPARC_32 _text > > .tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses': > > : relocation truncated to fit: R_SPARC_32 _text > > .tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses': > > : relocation truncated to fit: R_SPARC_32 _text > > > > (several more) > > > > I finally bisected it down to this commit: > > > > commit f9247273cb69ba101877e946d2d83044409cc8c5 > > Author: Steven Whitehouse <swhiteho@xxxxxxxxxx> > > Date: Thu Jul 24 17:22:13 2008 +0100 > > > > UFS: add const to parser token table > > > > Reverting this commit and the followup commit: > > > > commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43 > > Author: Adrian Bunk <bunk@xxxxxxxxxx> > > Date: Fri Jul 25 02:55:49 2008 +0300 > > > > fix fs/nfs/nfsroot.c compilation > > > > allows the sparc32 build to succeed. This is toolchain specific as a > > different cross toolchain I have does not get this error. > > > > Failing toolchain: > > > > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc --version > > sparc64-unknown-linux-gnu-gcc (GCC) 3.4.5 > > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-ld --version > > GNU ld version 2.15 > > > > An OK toolchain: > > $ cross/bin/sparc64-linux-gcc --version > > sparc64-linux-gcc (GCC) 4.2.4 > > $ cross/bin/sparc64-linux-ld --version > > GNU ld (GNU Binutils) 2.18 > > > > Both these commits are actually in Linus' tree, now. > > gee. nfsroot.c is now effectively doing `const __initconst' which > might be upsetting the compiler. And perhaps one of the forty-odd > other users of match_table_t needs __initconst or somesuch. > According to my find & grep there is only the one place which has marked out the match_table_t for a different section. > Yes, I'd second a revert-and-try-again-later on that one. It looks like there is no simple solution, so I guess we'll have to do that :( The only other alternative would be to remove the __initconst which isn't ideal either, Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
