3

My native gcc says, that its triplet is the following.

> gcc -dumpmachine
x86_64-suse-linux

Where cpu-vendor-os are correspondingly x86_64, suse, linux. The latter means that glibs is in use(?). When I am doing cross-compiling busybux-based system the compiler triplet is something like avr32-linux-uclibc, where os is 'linux-uclibc', meaning that uclibc is used.

The difference between 'linux-glibc' and 'linux-uclibc' is (AFAIU) in collect2 behavior and libgcc.a content. Either glibc or uclibs are silently linked to the target binary.

The questions is that how is the linux kernel been compiled by the same compilers? As soon as the kernel runs on bare-metal it must not been linked with any kind of user-space libc, and should use appropriate libgcc.a

artless noise
  • 21,212
  • 6
  • 68
  • 105
0x2207
  • 878
  • 1
  • 6
  • 20
  • Some compilers use a *quadruplet*. The form is *architechure*-*vendor*-*os*-*library*. But even this is not sufficient as *FPU*, *object format* and other conventions may apply. At the root, `gcc` just supports a prefix that is free form. People come up with names and there is no unifying body to make them unique. `-dumpspecs`, etc can be used to help identify the compiler. – artless noise Nov 08 '13 at 19:13

1 Answers1

3

gcc has all kind of options to control how it works. Here's a few relevant ones:

  • -nostdlib to omit linking to the standard libraries and startup code
  • -nostdinc to omit searching for header files in the standard locations.
  • -ffreestanding to compile for a freestanding environment (such as a kernel)

You also do not need to use gcc for linking. You can invoke the linker directly, supply it with your own linker map, startup object code, and anything else you need.

The linux kernel build seems, for arbitrary reasons not to use -ffreestanding , it does control the linking stage though, and ensures the kernel gets linked without pulling in any userspace code.

nos
  • 223,662
  • 58
  • 417
  • 506
  • In this case would it be possible to use x86_64-suse-linux-uclibc instead of x86_64-suse-linux-glibc by just specifying '-nostdlib -nostdinc -I ... -L ... -l ...'? This means that specifying linux-uclibc is redundant. – 0x2207 Nov 07 '13 at 18:13
  • For compiling a kernel it shouldn't matter which of the two you use, for user space applications it should be possible, but quite cumbersome as you'd have to manually pull in the proper startup code and libraries, and possibly a different linker map, as well as supplying or overriding preprocessor macros if there's any code that relies on e.g. a #define being present for telling the difference between glibc and uClibc. – nos Nov 07 '13 at 18:20
  • 1
    Linux has some built-in functionality normally provided by *libgcc*. I hope this is the same independent of the *libc* used. For the ARM, you can still mess up the kernel if you use a compiler with different register conventions. For identical compiler options, except for the library (glibc/eglibc vs uclibc vs newlib), your answer might be correct. Here is [an example](http://stackoverflow.com/questions/12174247/android-ndk-8b-cannot-load-library) libgcc function generated by the compiler, but not available in the system. Linux has many internal *libgcc* functions in it's source. – artless noise Nov 08 '13 at 19:19