in the code (.c file) how I can find the linux distribution name version - c++

I'd like to know in the code (.c file) how I can find the linux distribution name version (like ubuntu 10.0.4, or centOS 5.5...)?
The c function that I'm looking for should be like the uname() system call used in (.c files) to get kernel version.
it will be appreciated that the function is working for all linux distribution (standard)
I 'm not looking to get distribution name and version by the use of command line linux from code (.c file) (like the use of system("cat /etc/release");).
Any suggestion will be appreciated!
Regards

There is no standard for this yet. You can query following files or check for existence:
/etc/lsb-release
/etc/issue
/etc/*release
/etc/*version

Well, you can (and should) use fopen and fgets instead of system("cat"), for reading /etc/release.
There's no universal method though, I can even build a linux image which has no filesystem at all (except initramfs) and definitely no distribution name.

AFAIK there isn't a standard system call to get this if uname(2) doesn't give you enough info.
Safest approach is probably to check for "/proc/version" and read that

You could fopen("/etc/lsb-release") and parse its contents. It looks like this:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"
This method is not universal. You'll need to make sure that it works on all distros that you care about (if it doesn't, I suggest you go with #ott--'s answer).

Is it acceptable to run some shell commands?
$ /usr/bin/lsb_release -r
Release: 11.04
$ /usr/bin/lsb_release -d
Description: Ubuntu 11.04
$ /usr/bin/lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

There is no portable way to do that, you'll have to use some OS detection tool/library.
Fortunately, there are a few out there. I know those 2 :
Facter, a professional (yet free/open) information gathering program in ruby : http://puppetlabs.com/puppet/related-projects/facter/
a shell script : http://www.novell.com/coolsolutions/feature/11251.html
(I used facter via puppet and it is very good.)
With a little additional scripting, you can use one of those program's output to generate a .h that you can then use in your code.
You can even integrate this generation as a step in your makefile.

I usually inspect /etc/issue; while (as others pointed out) it is not guaranteed, I've fount in the field that's quite reliable.
As far as I've experienced, it works on ubuntu, debian, redhat, centos, slackware and archlinux.

Related

Linux BTF: bpftool: Failed to get EHDR from /sys/kernel/btf/vmlinux

I am trying to start with BPF CO:RE Development.
Using Ubuntu 20.04 LTS in a VM, I needed to recompile the kernel and install pahole (from apt install dwarves) so that BTF is enabled (I set CONFIG_DEBUG_FS=y and CONFIG_DEBUG_INFO_BTF=y).
So my setup is:
Ubuntu 20.04
Kernel 5.4.0-90-generic
bpftool --version: /usr/lib/linux-tools/5.4.0-90-generic/bpftool v5.4.148
/sys/kernel/btf/vmlinux exists and can be read out with cat.
But bpftool shows the following error:
$ sudo bpftool btf dump file /sys/kernel/btf/vmlinux format c
libbpf: failed to get EHDR from /sys/kernel/btf/vmlinux
Error: failed to load BTF from /sys/kernel/btf/vmlinux: Unknown error -4001
From https://github.com/libbpf/libbpf/blob/master/src/libbpf.h
it looks like it is LIBBPF_ERRNO__FORMAT, /* BPF object format invalid */
but I can not find out what's wrong.
Does anybody know where the mistake might be?
Thanks in advance!
EDIT: Added bpftool version
You need to update bpftool to support a fallback to reading BTF as raw data if the input file is not an object file. The minimum bpftool version required is v5.5 as that's the Linux release where the patch landed. In general, I would recommend to always use the latest bpftool version as there are no backports.
Update:
It looks like bpftool only accepts a ELF-file with the compiled runnning kernel in it, but my /sys/kernel/btf/vmlinux is not:
$ file /sys/kernel/btf/vmlinux
/sys/kernel/btf/vmlinux: data
Same for /boot/vmlinuz:
$ sudo file /boot/vmlinuz-5.4.0-90-generic
/boot/vmlinuz-5.4.0-90-generic: Linux kernel x86 boot executable bzImage, version 5.4.0-90-generic (root#elde-dev) #101+test1 SMP Tue Nov 23 16:38:41 UTC 2021, RO-rootFS, swap_dev 0xD, Normal VGA
Does anybody know why my /sys/kernel/btf/vmlinux does not show the right format?
I found this workaround:
Using this script (https://elixir.bootlin.com/linux/latest/source/scripts/extract-vmlinux) as suggested here (https://unix.stackexchange.com/questions/610672/where-is-the-linux-kernel-elf-file-located) I could get the "working" vmlinux-file which then could be read by bpftool. But this can not really be the right way for BPF CO:RE I guess... Also, in all the tutorials, bpftool is used directly with /sys/kernel/btf/vmlinux.
So why do I get the wrong format?
EDIT: As suggested above, just downoad the newest linux kernel, compile bpftool from there and use that.

No source file for Netaccel_link error on running program

I have an OCaml program that worked fine on Ubuntu 16 but when recompiled and run on Ubuntu 20 I get the following error:-
$ ocamldebug ./linearizer
OCaml Debugger version 4.08.1
(ocd) r
Loading program... done.
Time: 89534
Program end.
Uncaught exception: Sys_error "Illegal seek"
(ocd) b
Time: 89533 - pc: 624888 - module Netaccel_link
No source file for Netaccel_link.
I thought this was due to missing dev libraries but:-
$ sudo apt install libocamlnet-ocaml-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libocamlnet-ocaml-dev is already the newest version (4.1.6-1build6).
0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded.
What setup step am I missing on Ubuntu 20?
This looks like a regression bug in libocamlnet and you should report an issue there or, I am a bit pessimistic that you will get any response, you can try to debug the issue yourself.
The problem that you are facing has nothing to do with missing libraries (they will be reported during installation or, if the package is broken, end up in linker errors). It may result, however, from some misconfiguration of the system. If that is true, then you're lucky as you can fix it yourself.
I will give you some advice that might help you in debugging this issue. For more, please try using discuss.ocaml.org as a more suitable media (SO doesn't favor this kind of a discussion and we might get deleted by admins).
The illegal seek exception is thrown when the seek operation is applied on a non-regular file, aka ESPIPE Unix error. So check your inputs. It could be that what was previously regarded as a file in Ubuntu is now a pipe or a socket.
Try to use ltrace or strace to pinpoint the culprit e.g.,
ltrace ./linearizer
or, if it overwhelms you, try strace
strace ./linearizer
Instead of using ocamldebug you can use plain gdb. You can use gdb's interfaces to provide the path to the source code (though most likely it won't work since ocamlnet is not compiled with debug information). I believe that it will give you a more meaningful backtrace.
Instead of using the system installation try using opam. Install your dependencies with opam and try older versions as well as newer versions of the OCaml compiler. Also, try different versions of ocamlnet. Ideally, try to reproduce the environment that used to work for you.
When nothing else works, you can use objdump -d and look at the disassembly of your binary. OCaml is using a pretty readable and intuitive name mangling scheme (<module_name>__<function_name>_<uid>), so you can easily find the source code (search for <module_name>.ml file and look for the <function_name> there)
Finally, just use docker or any other container to run your application. Consider switching from ocamlnet to something more modern and supported.

Installing HDF5 library on Cygwin: "make check" stuck at testswmr.sh, no error message

I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry

how I get version of a program in linux

In Windows you can do:
CSystemInfo info;
this->m_strVersion = info.GetFileVersion( CFileSystemHelper::GetApplicationPath() + _T("/test.exe") );
to get the version number.
How would I do it in C++ on linux ?
Windows adopts a version resource system with standard API support, Linux and UNIX have no such high level concepts for a variety of reasons ranging from legacy to redundancy.
Best options are to query the local packaging system (RPM, APT, etc), or try executing with --version command line parameter which is a recommended GNU standard.
Example RPM query on command line for the Samba tool smbget:
# rpm -q -f /usr/bin/smbget --queryformat '%{version}\n'
3.0.33
You probably want to retrieve the path of the currently executing executable.
On Linux, you could use the /proc/ pseudo-file system. Read the proc(5) man page for more.
Specifically, you probably want to do something like
char myexepath[512];
memset (myexepath, 0, sizeof(myexepath);
readlink ("/proc/self/exe", myexepath, sizeof(myexepath));
(but you really should check for runtime errors above)
If you simply wanted to display the version of a program, you should have a convention about it. Usually accepting --version as the program first argument.
I invite you to read Advanced Linux Programming.

Profiling C++ with Google Perf tools and Dynamic Libraries

I'm trying to profile a C++ application, that I did not write, to get a sense for where the major computation points are. I'm not a C++ expert and even less so C++ debugging/profiling expert. I believe I am running into a (common?) problem with dynamic libraries.
I compile link to Google CPU Profiler using (OS X, G++):
env LIBS=-lprofiler ./configure
make
make install
I then run profile the installed application (jags) with:
env CPUPROFILE=./jags.prof /usr/local/bin/jags regression.cmd
pprof /usr/local/bin/jags jags.prof
Unfortunately, I get the error:
pprof /usr/local/bin/jags jags.prof Can't exec "objdump":
No such file or directory at /usr/local/bin/pprof line 2833.
objdump /System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib: No such file or directory
The program dynamically links to libLAPACK.dylib. So prof does not seem to understand it (?). I thought about trying to statically link, but the documents associated with the program say that it is impossible to statically link in LAPACK or BLAS (two required libraries).
Is there a way to have the profiler ignore libLAPACK? I'm okay if it doesn't sample within libLAPACK. Or how might I get profiling to work?
This error was caused by jags being a shell script, that subsequently called profilable code.
pprof /usr/local/bin/REAL_EXEC jags.prof
fixes the problem.
I don't see a clean way to do it, but maybe there's a hacky workaround -- what happens if you hack the pprof perl script (or better a copy thereof;-), line 2834, so that instead of calling error it emits the message and then does return undef;?
If you're profiling on OSX, the Shark tool is really great as well. It's very simple to use, and has worked out of the box for me when I've tried it.