I am getting "E: 4.0 is not a supported Linux release" when I try and run ManualExamples on my Linux machine.
Terminal Output
pin/source/tools/ManualExamples$ ../../../pin -t obj-intel64/inscount0.so -- /bin/ls
E: 4.0 is not a supported linux release
Does pin not support latest linux kernel?
Thanks! Manish
Pin 3.0 is now available, and is compatible with Linux Kernels 4.0 or higher.
However, chances are your existing Pintool (i.e. Pin 2.x compatible) won't work with Pin 3.0 since it forces you to use PinCRT and doesn't let you link your tool with outside libraries.
Still, there is a workaround for using Pin 2.x on kernels 4.0 or higher. Just use -injection child or -injection parent with your Pintool. For some reason Pin doesn't seem to care which kernel version you are running in these cases.
pin_kit$ uname -a
Linux 4.8.0-28-generic #30-Ubuntu SMP Fri Nov 11 14:03:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
pin_kit$ ./pin -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
E:4.8 is not a supported linux release
pin_kit$ ./pin -injection child -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
doc extras ia32 inscount.out intel64 LICENSE pin pin.log pin.sh README redist.txt source
pin_kit$ ./pin -injection parent -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
doc extras ia32 inscount.out intel64 LICENSE pin pin.log pin.sh README redist.txt source
There is not yet a Pin release available that supports Linux kernels 4.0 or higher.
You could try DynamoRIO instead:
$ cd DynamoRIO-Linux-6.1.0-2
$ bin64/drrun -c samples/bin64/libinscount.so -- /bin/ls
Client inscount is running
ACKNOWLEDGEMENTS bin64 docs drmemory ext lib32 License.txt README tools
bin32 cmake drcov.out dynamorio include lib64 logs samples
Instrumentation results: 506331 instructions executed
Use the -ifeellucky option. It works for me in 4.5 kernel.
Related
How to extract and compare the libc versions at runtime with the following restrictions?
stable solution (commands output parsing is discarded as this may vary)
should not rely on executing external tools like ldd, gcc or others
must work on a statically linked binary (AppRun)
will be implemented in C
Context:
In the AppImage project have been working on a feature to allow creating backward compatible bundles. To achieve this we created a program named AppRun. Things program compares the system glibc version with the one shipped in the bundle and configures the bundle to use the newer at runtime. This program is statically linked and should not depend on external tools.
Right now we scan the libc.so file for occurrences of GLIBC_X.XX and store the greater. But this is no longer working in the latest binary include in Ubuntu 20.04. The binary is 2.31 but there are no GLIBC_2.31 strings in the file therefore the method fails.
Related issues:
https://github.com/AppImageCrafters/AppRun/issues/35
https://github.com/AppImageCrafters/appimage-builder/issues/145
This program compares the system glibc version with the one shipped in the bundle and configures the bundle to use the newer at runtime.
Note that "configuring at runtime" involves more than just pointing the programs to the "correct" libc.so.6, as this answer explains.
Right now we scan the libc.so file for occurrences of GLIBC_X.XX and store the greater. But this is no longer working in the latest binary include in Ubuntu 20.04.
You appear to have a fundamental misunderstanding of how symbol versioning works. This answer may help understanding this better.
Your method is working.
The binary is 2.31 but there are no GLIBC_2.31 strings in the file therefore the method fails.
As above referenced answer explains, this means that GLIBC-2.31 didn't introduce any new ABI-incompatible symbols, and programs linked against that version of GLIBC will work when older GLIBC version is present at runtime (but may run into GLIBC bugs fixed between versions 2.30 and 2.31, etc.).
the libc versions
There are alternatives to glibc.
Right now we scan the libc.so file for occurrences of GLIBC_X.XX
Search for the string that glibc prints - GNU C Library <pkg+release_name> release version <version>[,.]..., and version has format [0-9]+\.[0-9]+(\.[0-9]+)?.
Just find libc.so.6 in /etc/ld.so.cache.
Do this in C:
libcfile="$(grep -azm1 '/libc.so.6$' /etc/ld.so.cache | tr -d '\0')"
grep -aoP 'GNU C Library [^\n]* release version \K[0-9]*.[0-9]*' "$libcfile"
Looking at commits, this should work since forever:
https://github.com/bminor/glibc/blame/b7eb84454020c59d528e826ae1889f411ed69e26/version.c#L28
https://github.com/bminor/glibc/blame/9f70e81bcaa12b0673cd0879d6f4a21ad6dddce5/version.c#L28
https://github.com/bminor/glibc/blame/92e4b6a92716f8b2457376291171a6330d072b0d/csu/version.c#L27
https://github.com/bminor/glibc/blame/50c66c7acd90f257b295e58bf938ed120cbc27c7/csu/version.c#L27
https://github.com/bminor/glibc/blame/b92a49359f33a461db080a33940d73f47c756126/csu/version.c#L27
Seems to work on the oldest ubuntu in docker I can find:
$ cmd='grep -aoP "GNU C Library [^\n]* release version \K[0-9]*.[0-9]*" "$(grep -azm1 "/libc.so.6$" /etc/ld.so.cache | tr -d "\0")"'
$ echo -n 'local: '; sh -c "$cmd"; for i in 13.04 16.04 14.04 22.04 21.10 20.04 18.04; do echo -n "ubuntu:$i "; docker run -ti --rm ubuntu:$i sh -c "$cmd"; done
local: 2.33
ubuntu:13.04 2.17
ubuntu:16.04 2.23
ubuntu:14.04 2.19
ubuntu:22.04 2.34
ubuntu:21.10 2.34
ubuntu:20.04 2.31
ubuntu:18.04 2.27
I also tested opensuse12.2 with glibc2.15, libc.so.6 prints GNU C Library stable release version 2.15 (20120628), by Roland McGrath et al. there.
I'm helping others doing a lab experiment of the "operating systems concepts" course. The experiment task is to compile Linux 2.6.26 and run it in QEMU.
After compiling the Linux kernel, we're told to write a smallest program to serve as the init program. The example we're presented (and we followed) is:
#include <stdio.h>
int main() {
while (1) {
puts("Hello!");
sleep(2);
}
}
The compilation command is:
root#ubuntu:/home/vmware/oslab# gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root#ubuntu:/home/vmware/oslab# gcc -static -o init hello.c
The host environment should be a freshly-installed Ubuntu 14.04.6 (i386).
The problem is, one of my fellow students followed the instruction carefully, and the init program failed to execute. I asked him for his whole initrd.img, and noticed how his init program looks different:
vmware#ubuntu:~/oslab$ file mnt/init
mnt/init: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=7365ac494ef1d924c171899c169dbd3195d2d209, not stripped
To me, that's clearly not something that can run on Linux 2.6.26. With GCC 4.8 provided in the Ubuntu APT repository (trusty), how can I get GCC to output something that runs on Linux 2.6.26?
FYI: On my own testing VM (also Ubuntu 14.04.6, Linux 4.4, same latest GCC version from Ubuntu APT repo as of April 2, 2019), the compiled program shows Linux 2.6.24 in file output. Also, his binary runs perfectly well in QEMU with my freshly compiled 2.6.32.37 kernel.
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.
The provided lab environment was Ubuntu 14.04, where the package libc6 has version 2.19-0ubuntu6.14.
The lab instruction provided by the teaching assistants contained an instruction to change the APT source by editing /etc/apt/sources.list manually, which had a SERIOUS disaster in it: The "version" string in the edited example was xenial instead of trusty, which, if followed, would factually update your system to Xenial (Ubuntu 16.04). The new version of libc6 was 2.23-0ubuntu11, which would cause as and ld (from binutils, not related to GCC) to output ELF with a minimum Linux version of 2.6.32.
With glibc version 2.19, the output ELF is compatible with Linux 2.6.24, but with glibc 2.23, the output is only compatible with Linux 2.6.32.
I tested and verified this by compiling a test program under Ubuntu 14.04 and checking the ELF information, then replaced all trusty with xenial, did apt-get update and only updated binutils and its dependencies (which includes libc6), and compiled the program and checked it again.
I am a beginner learning linux kernel module development. I am following a tutorial that says to recompile my kernel so as to enable various debugging features like forced module unloading e.t.c. Is is okay if I do that? Does it effects my pre-built kernel. In what cases that I am forced to insert a module into a running kernel and the kernel won't allow me to do so?
It is perfectly okay to compile and install a kernel to do kernel module development. If you are in ubuntu, you can follow the following steps to make sure that you are using the same kernel sources as your booted machine.
Step 1. Find out the linux being used in your booting from /boot/grub/grub.cfg file. Look for the entry agains 'linux ' in the boot option entries that you select while booting up.
Example excerpt : linux /boot/vmlinuz-3.13.0-24-generic root=UUID=e377a464-92db-4c07-86a9-b151800630c0 ro quiet splash $vt_handoff
Step 2. Look for the name of the package with the same version using the following command.
dpkg -l | grep linux | grep 3.13.0-24-generic
Example output:
$ dpkg -l | grep linux | grep 3.13.0-24-generic
ii linux-headers-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel headers for version 3.13.0 on 64 bit x86 SMP
ii linux-image-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii linux-image-extra-3.13.0-24-generic 3.13.0-24.46 amd64 Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
Step 3. Download sources of the package "linux-headers-3.13.0-24-generic" to get the same kernel that was used in your PC.
$ apt-get source linux-headers-3.13.0-24-generic
Step 4. Use the config file that is available at /boot/ folder as the config file to compile this kernel source
Example :
$ ls /boot/config-3.13.0-24-generic (Notice the same version used in this file)
Step 5. Turn on your debugging symbols on this config to do your testing.
Recompiling kernel help us to learn how kernel work.
latest kernel patches can be applied through kernel compile and install.
We can enable debug flag through compilation.
We can remove the not needed code.
Helps to add your own kernel code and test your code.
It is easy to recompile and install the linux kernel but it takes more time if we compile using low speed computer or VM.
For my current project, I need to use CUDA and the Intel C/C++ compilers in the same project. (I rely on the SSYEV implementation of Intel's MKL, which takes roughly 10 times as long when using GCC+MKL instead of ICC+MKL (~3ms from GCC, ~300µs from ICC).
icc -v
icc version 12.1.5
NVIDIA states, that Intel ICC 12.1 is supported (http://docs.nvidia.com/cuda/cuda-samples/index.html#linux-platforms-supported), but even after having downgraded to Intel ICC 12.1.5 (installed as part of the Intel Composer XE 2011 SP1 Update 3), I am still running into this issue:
nvcc -ccbin=icc src/test.cu -o test
/usr/local/cuda-5.5/bin//..//include/host_config.h(72): catastrophic error: #error directive: -- unsupported ICC configuration! Only ICC 12.1 on Linux x86_64 is supported!
#error -- unsupported ICC configuration! Only ICC 12.1 on Linux x86_64 is supported!
Unfortunately, it seems as if Nvidia is merely tolerating the use of ICC, because I would hardly call it "support", given the lack of information provided by Nvidia for using ICC together with CUDA.
I am running Ubuntu 12.10 x86_64 and CUDA 5.5. Telling icc to mimick the behavior of the stock GCC 4.7.2 using the -Xcompiler -gcc-version=470 option did not help either. Using google/search, I was only able to find threads from the Nvidia forums dealing with CUDA 3.x and Intel ICC 11.1, but I was unable to transfer the obtained information to current CUDA releases.
I would be very grateful for any suggestion on how to solving this issue :-)
Referring to the file referenced in the error you received, it's specifically looking for an ICC compiler with a particular build date:
#if defined(__ICC)
#if !(__INTEL_COMPILER == 9999 && __INTEL_COMPILER_BUILD_DATE == 20110811) || !defined(__GNUC__) || !defined(__LP64__)
#error -- unsupported ICC configuration! Only ICC 12.1 on Linux x86_64 is supported!
#endif
The solution would be to have the intel compiler that actually matches that specified build date. As indicated, ICC 12.1, ie. version 12.1.0.233, instead of ICC 12.1.5 should do the trick.
The narrow focus is at least partly due to a test limitation. In this case, a particular ICC variant was tested with the CUDA toolkit before it was released, and so that host config check has this test in it.
I confronted the problem when compiling madagascar-1.5 with icc2013 and ifort2013. Then I try to resolve the problem by downloading ICC version 2011 update7. Based the INTEL_COMPILER_BUILD_DATE which is 20110811, I can download the correct one. I think the date 20110811 matched icc is the correct one.
I met an err when I installed JikesRVM, that is,
skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.4/libstdc++.so when searching for -lstdc++
So I am trying to install/update it to a later version. Now, the machine already has
gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
I am new to openSUSE, could you help?
Thanks!
You need to install 32 bit support for the GNU C/C++ compiler since JikesRVM on x86_64 currently supports only the 32 bit architecture.
To install this support in OpenSuSE 11.2 type
sudo zypper install gcc44-32bit gcc-32bit libstdc++44-devel-32bit
The first two provide runtime support for the C language and the 32-bit version of libgcc, the GCC low level runtime library. The third provides the 32-bit version of libstdc++, both the static import library and the dynamic library. It is the static libstdc++.a that was missing for JikesRVM.
To verify that the 32bit C++ build system is installed correctly you can test it with the following
echo "int main(){}" | g++ -x c++ -m32 -
Note Official support for OpenSuSE 11.2 has ended. Evergreen support will be available through 2013. Yet it is reasonable to update to 11.3 or a later version soon.