Linux Command "File" Shows "For Gnu/Linux 2.6.24"

linux command file shows for GNU/Linux 2.6.24

The kernel version displayed by file on an executable has nothing to do with the kernel installed on your system. It matches the C library the program was linked with at build time.

Your C compiler targets a specific C library (usually glibc). In turn, the C library targets a kernel API (i.e. the C library is built for a specific kernel). That is the version displayed by file.

You don't have to worry about the mimatch between the kernel version displayed by file and the kernel version installed on your machine.

@REALFREE: you can try the following experiment. Maybe it will
help you get a grasp of what's going on:

$ uname -r
3.10-2-amd64
$ gcc -Wall -Werror hello.c -o hello
$ readelf --notes ./hello
Displaying notes found at file offset 0x0000021c with length 0x00000020:
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 2.6.32

The information about the ABI tag is contained in an elf
segment called NOTE. This information is written by the linker
when the program is compiled. It matches the ABI tag of the C library.

$ ldd ./hello
        linux-vdso.so.1 (0x00007fffd31fe000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5f1a465000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5f1a827000)
$ readelf --notes /lib/x86_64-linux-gnu/libc.so.6
Displaying notes found at file offset 0x00000294 with length 0x00000020:
  Propriétaire        Taille des données        Description
  GNU                  0x00000010       NT_GNU_ABI_TAG (étiquette de version ABI)
    OS: Linux, ABI: 2.6.32

In order to build the C library, you have to select a kernel
version. Here, the C library was compiled for a 2.6.32 kernel but
it also works with more recent kernels. However, if the program
is run on a kernel older than 2.6.32, a kernel too old warning
is displayed.

Why linux version of system binary file is not consistent with system release version?

This tag shows that the ELF binary was compiled with a glibc that produces binaries which require this specific minimun linux kernel version to run.
The version number is set at glibc's compile time using config option --enable-kernel, and is copied by the linker on the binary's SHT_NOTE section (from where it is read by the file command).

Specify the expected Linux version of the output binary of GCC

Specify the expected Linux version of the output binary of GCC

in your question you speak about the version of libc C but that can also concerns a lot of other libs, and may be you want also produce 32b and/or 64b executable(s).

For me the most secure way is to use pbuilder, I use it to produce BoUML debs for Ubuntu Cosmic (18.10) Bionic (18.04), Artful (17.10) Zesty (17.04) Yakkety (16.10) Xenial (16.04) Trusty (14.04) and Precise (12.04) and that in both 32b and 64b, and I do all of that from my Ubuntu Xenial 64b just doing the appropriate sequence of pbuilder commands (without any reboot to go in each Linux release)

That needs time to generate a version but because this is made in the corresponding Linux version you are sure of the result.

Linux using command file -i return wrong value charset=unknow-8bit for a windows-1252 encoded file

It's important to understand what a character encoding is and isn't.

A text file is actually just a stream of bits; or, since we've mostly agreed that there are 8 bits in a byte, a stream of bytes. A character encoding is a lookup table (and sometimes a more complicated algorithm) for deciding what characters to show to a human for that stream of bytes.

For instance, the character "€" encoded in Windows-1252 is the string of bits 10000000. That same string of bits will mean other things in other encodings - most encodings assign some meaning to all 256 possible bytes.

If a piece of software knows that the file is supposed to be read as Windows-1252, it can look up a mapping for that encoding and show you a "€". This is how browsers are displaying the right thing: you've told them in the Content-Type header to use the Windows-1252 lookup table.

Once you save the file to disk, that "Windows-1252" label form the Content-Type header isn't stored anywhere. So any program looking at that file can see that it contains the string of bits 10000000 but it doesn't know what mapping table to look that up in. Nothing you do in the HTTP headers is going to change that - none of those are going to affect how it's saved on disk.

In this particular case the "file" command could look at the "encoding" marker inside the XML document, and find the "windows-1252" there. My guess is that it simply doesn't have that functionality. So instead it uses its general logic for guessing an encoding: it's probably something ASCII-compatible, because it starts with the bytes that spell <?xml in ASCII; but it's not ASCII itself, because it has bytes outside the range 00000000 to 01111111; anything beyond that is hard to guess, so output "unknown-8bit".

Error when trying to run an executable on a Linux system

gcc -c doesn't generate executables; it generates object files. Remove the -c if you want an executable.

Compile a linux 2.6 kernel module with newer compiler

Your kernel version is too old and it is missing linux/compiler-gcc5.h.

The header is included from linux/compiler-gcc.h and its name is generated by preprocessor macro based on current compiler version:

#define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)

This header was introduced around version 3.18.

You might try to get this file from a newer kernel source and put in into include/linux.

---

Related Topics