Re: Linux kernel cross-compilers
> > > > I found out the root source: SHELL is set the /bin/sh, which on the failing > > system points to /bin/dash (default in Ubuntu, or at least it used to be). > > dash apparently has a built-in version of echo which does not understand > > '-e'. > > Oh well. > > Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__. > Will send a patch for that. Could you please take a look at the other places that uses "echo -e". At least one usage inarch/x86/Makefiel looks questionable. grep did not turn up many uses. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Oh well. Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__. Will send a patch for that. Could you please take a look at the other places that uses echo -e. At least one usage inarch/x86/Makefiel looks questionable. grep did not turn up many uses. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 09:26:51PM +0200, Sam Ravnborg wrote: > On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote: > > On 08/16/2013 02:45 AM, Max Filippov wrote: > Guenter, > can you share a complete build log with V=1? > > >>> > >>> http://roeck-us.net/linux/logs/make.xtensa.log.bad > >>> http://roeck-us.net/linux/logs/make.xtensa.log.ok > >>> > >>> Key difference: the failing command in the bad case is > >>> xtensa-linux-objcopy -O elf32-xtensa-le > >>> and in the good case > >>> xtensa-linux-objcopy -O elf32-xtensa-be > >>> > >>> Same compiler (4.6.3 from kernel.org), same configuration file, same > >>> command > >>> line. > >>> Configuration file is generated from defconfig, and the resulting .config > >>> file > >>> is the same in both cases. > >>> > >>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as > >>> parameter to it, > >>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. > >>> > >>> I am puzzled. Guess there must be something different, but I have no idea > >>> what it might be. > >> > >> What is the output of > >> > >> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - > >> > >> on the failing system? > >> > > It is "1", but that let me pinpoint the problem. > > > > On the failing system, the version of echo executed by make does > > not understand the "-e" option. Thus, when running > > arch/xtensa/boot/Makefile, > > "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile, > > and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. > > > > I found out the root source: SHELL is set the /bin/sh, which on the failing > > system points to /bin/dash (default in Ubuntu, or at least it used to be). > > dash apparently has a built-in version of echo which does not understand > > '-e'. > > Could you try to replace "echo -e bla" with "printf "bla". > Kbuild.include uses some similar tricks but here printf is used. > Maybe this can be dash compatible then > "echo" would do perfectly fine in this case. Besides, there are more "echo -e" in arch/xtensa/Makefile. Those only cause unpredictable build results (because neither big endian not little endian is set because of it), but no errors. Problem is that "echo -e" is used elsewhere in various kernel makefiles, not just for xtensa. Those don't cause odd errors like the one I observed, but may result in unpredictable behavior. I am not sure if I should try to fix that. Maybe we should just put "don't try to compile the linux kernel with dash as default shell" as a note somewhere. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 7:43 PM, Guenter Roeck wrote: > On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? >>> >>> http://roeck-us.net/linux/logs/make.xtensa.log.bad >>> http://roeck-us.net/linux/logs/make.xtensa.log.ok >>> >>> Key difference: the failing command in the bad case is >>> xtensa-linux-objcopy -O elf32-xtensa-le >>> and in the good case >>> xtensa-linux-objcopy -O elf32-xtensa-be >>> >>> Same compiler (4.6.3 from kernel.org), same configuration file, same >>> command >>> line. >>> Configuration file is generated from defconfig, and the resulting .config >>> file >>> is the same in both cases. >>> >>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as >>> parameter to it, >>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. >>> >>> I am puzzled. Guess there must be something different, but I have no idea >>> what it might be. >> >> >> What is the output of >> >> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - >> >> on the failing system? >> > It is "1", but that let me pinpoint the problem. > > On the failing system, the version of echo executed by make does > not understand the "-e" option. Thus, when running > arch/xtensa/boot/Makefile, > "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile, > and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. > > I found out the root source: SHELL is set the /bin/sh, which on the failing > system points to /bin/dash (default in Ubuntu, or at least it used to be). > dash apparently has a built-in version of echo which does not understand > '-e'. > Oh well. Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__. Will send a patch for that. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote: > On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? >>> >>> http://roeck-us.net/linux/logs/make.xtensa.log.bad >>> http://roeck-us.net/linux/logs/make.xtensa.log.ok >>> >>> Key difference: the failing command in the bad case is >>> xtensa-linux-objcopy -O elf32-xtensa-le >>> and in the good case >>> xtensa-linux-objcopy -O elf32-xtensa-be >>> >>> Same compiler (4.6.3 from kernel.org), same configuration file, same command >>> line. >>> Configuration file is generated from defconfig, and the resulting .config >>> file >>> is the same in both cases. >>> >>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as >>> parameter to it, >>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. >>> >>> I am puzzled. Guess there must be something different, but I have no idea >>> what it might be. >> >> What is the output of >> >> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - >> >> on the failing system? >> > It is "1", but that let me pinpoint the problem. > > On the failing system, the version of echo executed by make does > not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile, > "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile, > and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. > > I found out the root source: SHELL is set the /bin/sh, which on the failing > system points to /bin/dash (default in Ubuntu, or at least it used to be). > dash apparently has a built-in version of echo which does not understand '-e'. Could you try to replace "echo -e bla" with "printf "bla". Kbuild.include uses some similar tricks but here printf is used. Maybe this can be dash compatible then Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? It is "1", but that let me pinpoint the problem. On the failing system, the version of echo executed by make does not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile, "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile, and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Oh well. Thanks a lot for helping me to track this down! Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
>> Guenter, >> can you share a complete build log with V=1? >> > > http://roeck-us.net/linux/logs/make.xtensa.log.bad > http://roeck-us.net/linux/logs/make.xtensa.log.ok > > Key difference: the failing command in the bad case is > xtensa-linux-objcopy -O elf32-xtensa-le > and in the good case > xtensa-linux-objcopy -O elf32-xtensa-be > > Same compiler (4.6.3 from kernel.org), same configuration file, same command > line. > Configuration file is generated from defconfig, and the resulting .config > file > is the same in both cases. > > If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as > parameter to it, > it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. > > I am puzzled. Guess there must be something different, but I have no idea > what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 01:31 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck wrote: On 08/16/2013 12:22 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. CONFIG_LD_NO_RELAX doesn't help. For reference, here is the error: xtensa-linux-objcopy: Unable to change endianness of input file(s) make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 make[1]: *** [boot-elf] Error 2 make: *** [zImage] Error 2 Oddly enough, I only see the problem on one of three servers. Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. If I execute the command which sets BIG_ENDIAN manually from the shell (from arch/xtensa/boot/Makefile), it returns 1 on both systems. If you have an idea what is going on please let me know. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck wrote: > On 08/16/2013 12:22 AM, Max Filippov wrote: >> >> On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds >> wrote: >>> >>> On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: >>> Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. >>> >>> >>> Is there something I can do at linker build time to help with this? >> >> >> I don't think so. Apparently it's not a linker configuration issue, it's a >> bug. >> > CONFIG_LD_NO_RELAX doesn't help. > > For reference, here is the error: > > xtensa-linux-objcopy: Unable to change endianness of input file(s) > make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 > make[1]: *** [boot-elf] Error 2 > make: *** [zImage] Error 2 > > Oddly enough, I only see the problem on one of three servers. Guenter, can you share a complete build log with V=1? -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/15/2013 10:47 PM, Tony Breeds wrote: On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: Hi Tony, would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. Would be great. Also, the xtensa compiler fails for me with an odd error message on one of my servers. Have you heard about any problems with it from others ? Nope. Sorry, but it looks like you're being looked after there. No far not helping. I had hoped it is a known problem that has been fixed with a later gcc or binutils version, but it looks like it isn't widely seen. c6x is supposed to be supported by gcc now. No idea if that helps anything, though. Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't worked todate. I'll keep trying as time permits. Too bad. Thanks for trying! Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 12:22 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. CONFIG_LD_NO_RELAX doesn't help. For reference, here is the error: xtensa-linux-objcopy: Unable to change endianness of input file(s) make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 make[1]: *** [boot-elf] Error 2 make: *** [zImage] Error 2 Oddly enough, I only see the problem on one of three servers. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds wrote: > On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: > >> Yes, xtensa compiler/linker is known to have issues with link-time >> relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. > > Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds t...@bakeyournoodle.com wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 12:22 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds t...@bakeyournoodle.com wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. CONFIG_LD_NO_RELAX doesn't help. For reference, here is the error: xtensa-linux-objcopy: Unable to change endianness of input file(s) make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 make[1]: *** [boot-elf] Error 2 make: *** [zImage] Error 2 Oddly enough, I only see the problem on one of three servers. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/15/2013 10:47 PM, Tony Breeds wrote: On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: Hi Tony, would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. Would be great. Also, the xtensa compiler fails for me with an odd error message on one of my servers. Have you heard about any problems with it from others ? Nope. Sorry, but it looks like you're being looked after there. No far not helping. I had hoped it is a known problem that has been fixed with a later gcc or binutils version, but it looks like it isn't widely seen. c6x is supposed to be supported by gcc now. No idea if that helps anything, though. Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't worked todate. I'll keep trying as time permits. Too bad. Thanks for trying! Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck li...@roeck-us.net wrote: On 08/16/2013 12:22 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds t...@bakeyournoodle.com wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. CONFIG_LD_NO_RELAX doesn't help. For reference, here is the error: xtensa-linux-objcopy: Unable to change endianness of input file(s) make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 make[1]: *** [boot-elf] Error 2 make: *** [zImage] Error 2 Oddly enough, I only see the problem on one of three servers. Guenter, can you share a complete build log with V=1? -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 01:31 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck li...@roeck-us.net wrote: On 08/16/2013 12:22 AM, Max Filippov wrote: On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds t...@bakeyournoodle.com wrote: On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? I don't think so. Apparently it's not a linker configuration issue, it's a bug. CONFIG_LD_NO_RELAX doesn't help. For reference, here is the error: xtensa-linux-objcopy: Unable to change endianness of input file(s) make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1 make[1]: *** [boot-elf] Error 2 make: *** [zImage] Error 2 Oddly enough, I only see the problem on one of three servers. Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. If I execute the command which sets BIG_ENDIAN manually from the shell (from arch/xtensa/boot/Makefile), it returns 1 on both systems. If you have an idea what is going on please let me know. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? It is 1, but that let me pinpoint the problem. On the failing system, the version of echo executed by make does not understand the -e option. Thus, when running arch/xtensa/boot/Makefile, echo -e __XTENSA_EB__ returns -e __XTENSA_EB__, which doesn't compile, and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Oh well. Thanks a lot for helping me to track this down! Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote: On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? It is 1, but that let me pinpoint the problem. On the failing system, the version of echo executed by make does not understand the -e option. Thus, when running arch/xtensa/boot/Makefile, echo -e __XTENSA_EB__ returns -e __XTENSA_EB__, which doesn't compile, and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Could you try to replace echo -e bla with printf bla. Kbuild.include uses some similar tricks but here printf is used. Maybe this can be dash compatible then Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 7:43 PM, Guenter Roeck li...@roeck-us.net wrote: On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? It is 1, but that let me pinpoint the problem. On the failing system, the version of echo executed by make does not understand the -e option. Thus, when running arch/xtensa/boot/Makefile, echo -e __XTENSA_EB__ returns -e __XTENSA_EB__, which doesn't compile, and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Oh well. Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__. Will send a patch for that. -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Fri, Aug 16, 2013 at 09:26:51PM +0200, Sam Ravnborg wrote: On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote: On 08/16/2013 02:45 AM, Max Filippov wrote: Guenter, can you share a complete build log with V=1? http://roeck-us.net/linux/logs/make.xtensa.log.bad http://roeck-us.net/linux/logs/make.xtensa.log.ok Key difference: the failing command in the bad case is xtensa-linux-objcopy -O elf32-xtensa-le and in the good case xtensa-linux-objcopy -O elf32-xtensa-be Same compiler (4.6.3 from kernel.org), same configuration file, same command line. Configuration file is generated from defconfig, and the resulting .config file is the same in both cases. If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it, it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails. I am puzzled. Guess there must be something different, but I have no idea what it might be. What is the output of echo -e __XTENSA_EB__ | xtensa-linux-gcc -E - on the failing system? It is 1, but that let me pinpoint the problem. On the failing system, the version of echo executed by make does not understand the -e option. Thus, when running arch/xtensa/boot/Makefile, echo -e __XTENSA_EB__ returns -e __XTENSA_EB__, which doesn't compile, and BIG_ENDIAN ends up being 0. So the compiler is completely innocent. I found out the root source: SHELL is set the /bin/sh, which on the failing system points to /bin/dash (default in Ubuntu, or at least it used to be). dash apparently has a built-in version of echo which does not understand '-e'. Could you try to replace echo -e bla with printf bla. Kbuild.include uses some similar tricks but here printf is used. Maybe this can be dash compatible then echo would do perfectly fine in this case. Besides, there are more echo -e in arch/xtensa/Makefile. Those only cause unpredictable build results (because neither big endian not little endian is set because of it), but no errors. Problem is that echo -e is used elsewhere in various kernel makefiles, not just for xtensa. Those don't cause odd errors like the one I observed, but may result in unpredictable behavior. I am not sure if I should try to fix that. Maybe we should just put don't try to compile the linux kernel with dash as default shell as a note somewhere. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: > Yes, xtensa compiler/linker is known to have issues with link-time > relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? Yours Tony pgpfaHO3TmWlK.pgp Description: PGP signature
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: > Hi Tony, > > would it be possible to provide an arm64 cross-compiler on > https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. > Also, the xtensa compiler fails for me with an odd error message on one of my > servers. > Have you heard about any problems with it from others ? Nope. Sorry, but it looks like you're being looked after there. > c6x is supposed to be supported by gcc now. No idea if that helps anything, > though. Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't worked todate. I'll keep trying as time permits. > > Thanks, > Guenter > Yours Tony pgpbYYVRdMEZ2.pgp Description: PGP signature
Re: Linux kernel cross-compilers
On 08/15/2013 07:22 AM, Max Filippov wrote: On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck wrote: On 08/15/2013 02:46 AM, Max Filippov wrote: Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? It complains about being unable to change the byte order in an object file. Actually, the message is from the linker, but I have no idea what is causing it. I've seen such message when I attempted to link a kernel, parts of which were by mistake compiled for different xtensa core variants. Clean rebuild fixed that. "clean -f -q -d -x" did not help in my case. It can't get much cleaner than that. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck wrote: > On 08/15/2013 02:46 AM, Max Filippov wrote: >> >> Hi Guenter, >> >> On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck wrote: >>> >>> Also, the xtensa compiler fails for me with an odd error message on one >>> of >>> my servers. >> >> >> What is the message? >> > It complains about being unable to change the byte order in an object file. > > Actually, the message is from the linker, but I have no idea what is causing > it. I've seen such message when I attempted to link a kernel, parts of which were by mistake compiled for different xtensa core variants. Clean rebuild fixed that. > It works on two servers but fails on the third. At least in theory the > installation > on all servers should be the same. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/15/2013 02:46 AM, Max Filippov wrote: Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? It complains about being unable to change the byte order in an object file. Actually, the message is from the linker, but I have no idea what is causing it. It works on two servers but fails on the third. At least in theory the installation on all servers should be the same. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck wrote: > Also, the xtensa compiler fails for me with an odd error message on one of > my servers. What is the message? > Have you heard about any problems with it from others ? Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck li...@roeck-us.net wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? Have you heard about any problems with it from others ? Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/15/2013 02:46 AM, Max Filippov wrote: Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck li...@roeck-us.net wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? It complains about being unable to change the byte order in an object file. Actually, the message is from the linker, but I have no idea what is causing it. It works on two servers but fails on the third. At least in theory the installation on all servers should be the same. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck li...@roeck-us.net wrote: On 08/15/2013 02:46 AM, Max Filippov wrote: Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck li...@roeck-us.net wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? It complains about being unable to change the byte order in an object file. Actually, the message is from the linker, but I have no idea what is causing it. I've seen such message when I attempted to link a kernel, parts of which were by mistake compiled for different xtensa core variants. Clean rebuild fixed that. It works on two servers but fails on the third. At least in theory the installation on all servers should be the same. -- Thanks. -- Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On 08/15/2013 07:22 AM, Max Filippov wrote: On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck li...@roeck-us.net wrote: On 08/15/2013 02:46 AM, Max Filippov wrote: Hi Guenter, On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck li...@roeck-us.net wrote: Also, the xtensa compiler fails for me with an odd error message on one of my servers. What is the message? It complains about being unable to change the byte order in an object file. Actually, the message is from the linker, but I have no idea what is causing it. I've seen such message when I attempted to link a kernel, parts of which were by mistake compiled for different xtensa core variants. Clean rebuild fixed that. clean -f -q -d -x did not help in my case. It can't get much cleaner than that. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote: Hi Tony, would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ? I have one built I just need to upload it. I'll try and do it this weekend. Also, the xtensa compiler fails for me with an odd error message on one of my servers. Have you heard about any problems with it from others ? Nope. Sorry, but it looks like you're being looked after there. c6x is supposed to be supported by gcc now. No idea if that helps anything, though. Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't worked todate. I'll keep trying as time permits. Thanks, Guenter Yours Tony pgpbYYVRdMEZ2.pgp Description: PGP signature
Re: Linux kernel cross-compilers
On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote: Yes, xtensa compiler/linker is known to have issues with link-time relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX. Is there something I can do at linker build time to help with this? Yours Tony pgpfaHO3TmWlK.pgp Description: PGP signature
