0

My question may sound like stupid but this is one simple problem I am facing for past 2 days. As of writing this question, the latest kernel version is 4.14 but I want to compile any randomly selected older version (v3.2).

I have cloned the kernel from mainline repo and checked out the proper version

git checkout -b v3.2 v3.2
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
make vexpress_defconfig
make -j8 all

This throws me the error : 

  CC      arch/arm/vfp/vfpsingle.o
  LD      usr/built-in.o
  CC      arch/arm/kernel/elf.o
  CC      arch/arm/vfp/vfpdouble.o
  CC      arch/arm/mm/dma-mapping.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/kernel/process.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/common/gic.o
  LD      init/mounts.o
init/do_mounts_initrd.o: In function `return_address':
/home/naveen/data/linux/arch/arm/include/asm/ftrace.h:51: multiple definition of `return_address'
init/do_mounts.o:/home/naveen/data/linux/arch/arm/include/asm/ftrace.h:51: first defined here
scripts/Makefile.build:427: recipe for target 'init/mounts.o' failed
make[1]: *** [init/mounts.o] Error 1
Makefile:945: recipe for target 'init' failed
make: *** [init] Error 2
make: *** Waiting for unfinished jobs....
  CC      arch/arm/common/icst.o
  CC      arch/arm/mm/extable.o
  CC      arch/arm/common/timer-sp.o
  CC      arch/arm/kernel/return_address.o
  CC      arch/arm/mm/fault.o
  CC      arch/arm/mm/init.o
  CC      arch/arm/mm/iomap.o
  CC      arch/arm/kernel/setup.o
  LD      arch/arm/common/built-in.o
arch/arm/kernel/return_address.c:62:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
arch/arm/kernel/return_address.c:65:7: error: redefinition of ‘return_address’
 void *return_address(unsigned int level)
       ^
In file included from include/linux/ftrace.h:19:0,
                 from arch/arm/kernel/return_address.c:12:
/home/naveen/data/linux/arch/arm/include/asm/ftrace.h:48:21: note: previous definition of ‘return_address’ was here
 extern inline void *return_address(unsigned int level)
                     ^
scripts/Makefile.build:305: recipe for target 'arch/arm/kernel/return_address.o' failed
make[1]: *** [arch/arm/kernel/return_address.o] Error 1
make[1]: *** Waiting for unfinished jobs....

All of my steps have been followed from this article which should have been working. All I can figure out (after referring other similar articles and questions on SO) that the compiler version being used does matter.

My current compiler version is :

insanecoder@worstation ~/data/linux $ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

My question is : Should I really take care of the compiler version (toolchain) while compiling linux kernel? If yes, how can I know what's the most suitable toolchain/compiler version for my specific kernel version.

I was of the viewpoint that any latest toolchain should take care of all the previous kernel versions. Old compilers may not be able to compile newer kernel versions due to missing compiler options, if used. However, vice-versa should not be an issue.

EDIT

The essence of this question is to locate a reliable source of information for any mainline linux kernel version, where one can find the information about the versions of compiler supported in order to compile it.

The objective is not to compile a specific version of kernel. e.g I am very well able to compile v4.9 with my existing setup. I just randomly chose an older version in order to validate my learning.

Naveen
  • 7,944
  • 12
  • 78
  • 165
  • Possible duplicate of [Error when compiling Linux kernel 3.2 for ARM](https://stackoverflow.com/questions/38287313/error-when-compiling-linux-kernel-3-2-for-arm) – Tsyvarev Feb 20 '18 at 12:48
  • @Tsyvarev Yes , as I mentioned in my question, I have already seen such questions and solutions related to using a different compiler version. My real question is , how would I determing the suitable toolchain/compiler version to be used for compiling a specific version of linux kernel? Is such information present in the release notes of kernel? – Naveen Feb 20 '18 at 12:56
  • Hm, `how would I determing the suitable toolchain/compiler version to be used for compiling a specific version of linux kernel?` - Check the docs for that kernel (README, Documentation/Changes, and so) or google. Note, that documentation usually notes only the minimal compiler version. That means that the kernel is compilable by any gcc released before the kernel: the kernel documentation is rarely updated just because new gcc is released. If you ask about *automatic* way for detect suitable compiler version, you seems out of luck. – Tsyvarev Feb 20 '18 at 13:05
  • 1
    There will be no 'reliable source' of information. GCC and Linux development occur in parallel for many different CPU types and boards (system designs). As Linux is cross platform it typically uses GCC only features which can/do change between GCC versions. As well, GCC optimizations change over time and occasionally some very esoteric bug is found via extremely tight non-linear Linux code paths. So what you ask for is very complex information to create and maintain and who would be motivated to create and maintain such a list? Latest kernel with the latest version or get backports. – artless noise Feb 20 '18 at 16:07
  • 1
    For instance, many GCC bugs only trigger when using ARM-Linux versions with some GCC versions; an ARM EABI defect in GCC. Typically if a defect is found, the compiler is blacklisted via compiler version checks in the make system. If the GCC version didn't exist when the kernel was release, then you have issues. Also, a Linaro compiler may have patches, so it is not a mainline GCC. – artless noise Feb 20 '18 at 16:11
  • @artlessnoise : You exactly hit the point. This question originated when I faced compilation error with one gcc version and not the other. And initially I actually thought someone touched my codebase, before later figuring out that it was compiler version issue and not actual errors – Naveen Feb 21 '18 at 05:10

0 Answers0