My question is simple... How could I check the version of GMP installed on my machine? What about MPFR? And What about CamlIDL?
Thank you very much
To check for GMP(MPIR) version, access string __gmp_version(__mpir_version) in dynamic library called libgmp.so.X.Y.Z(libmpir.so.X.Y.Z). Your standard library directory might contain more than one such file (this happens if you install newer version of GMP or MPIR but your package manager chooses to keep old version because it is still needed).
Cutting off a small Python code fragment from benchmark_det_Dixon.py:
import ctypes
so_name='/usr/lib/libgmp.so' # or /usr/lib64/libgmp.so, etc
var_name='__gmp_version'
L=ctypes.cdll.LoadLibrary(so_name)
v=ctypes.c_char_p.in_dll(L,var_name)
print(v.value)
The code above only works under Linux/Unix; it should be possible to port it to other OS supported by ctypes Python package.
To get MPFR version, call mpfr_get_version():
M=ctypes.cdll.LoadLibrary('/usr/lib/libmpfr.so') # or /usr/lib64, etc
M.mpfr_get_version.restype=ctypes.c_char_p
print(M.mpfr_get_version())
The standard Autoconf way to do this is to pick some library function that's in required minimum version X and not in version X-1, then see if you can successfully compile a tiny program that calls that function. It's not as elegant as querying some oracle for a version string, but it has the advantage of demonstrating that the build environment is actually correct.
Related
I am programming the Raspberry Pi Pico-W and I would like to link against the C++ STL, in order to use some of the Standard Library functionalities and containers.
I have found the package on Ubuntu, which I used in a professional development environment and I therefore also wanted to install it on Fedora 36, but found it missing in the official and unofficial repositories.
Following packages are available to me currently, so it is really just the libstdc++ that is missing, since the C Library (newlib) is there.
arm-none-eabi-binutils-cs.x86_64
arm-none-eabi-gcc-cs.x86_64
arm-none-eabi-gcc-cs-c++.x86_64
arm-none-eabi-newlib.noarch
libstdc++.i686
libstdc++.x86_64
libstdc++-devel.x86_64
One option I got recommended was to get the headers manually from arm itself, which also includes the rest of the toolchain.
Is there some package I am missing in the Fedora repositories, or is it just really not available as one package?
Fedora does not seem to provide such packages and I have also not been able to find copr repos for that.
Therefore the only solution left, was to install directly from arm.
This link gives a short guide for those that need it.
Additionally, since I am using NeoVim with its built-in lsp, I need to add a flag to the clangd configuration, namely --query-driver=/*/*/bin/*gcc, which globs for the compiler found in the compile commands. But this only as a side note.
After that everything seems to work as one would expect.
I'm working on a project in the D language and I want to use a module from the standard library called std.sumtype. I'm on debian oldstable, and I've tried both GDC and LDC. DMD is unavailable, because I'm using a machine with an armhf architecture. Neither of these compilers can find std.sumtype, despite it being in the standard library. I also tried downloading 3 different versions of sumtype.d from the phobos repositories of all three D compilers. Each of these would not compile. How can I use this? Am I on the wrong version?
std.sumtype is a pretty new package that was added in 2.097.0: https://dlang.org/changelog/2.097.0.html#std-sumtype so the debian oldstable packages probably don't have it yet as you would need at least:
DMD 2.097.0
LDC 1.27.0 (beta.1 or above)
upcoming GDC in May 2022 (see announcement)
If you want to use the latest compiler you could always download the latest LDC archive and extract it somewhere and run it from there or use the install.sh script from the download page for portable and multiple simultaneous installs.
std.sumtype is an adoption of the dub package sumtype so if you are using dub, you can depend on that as well and not need to get another compiler outside the package manager.
I am new to Linux programming and I wonder, is there a way to run (not recompile) my C++ executable on an older version of Linux of the same distribution?
Example: Say I compiled my code on RHEL 6 and want to run my executable on RHEL 4 or 5.
In Windows when we do this we just install the C++ runtime of the compiler version of C++.
Example: If I use VS2012 to build a C++ project using C++11, I just need to install the C++ runtime of C++11 on the client machine to run my application no matter what version of Windows I am using (of course starting from Windows XP)
The by far easiest way is to make use of the strong future compatibility of glibc and the GCC runtime libraries: compile your executable on the oldest OS you want it to run on, and it should work on anything later without recompiling (that is, some symlinks may be needed to satisfy the dependencies the executable loader is expecting).
In general it is best to compile it for each distribution you want to support, so no unexpected conflicts appear.
Actually, yes - Find your apps deps (using e.g: ldd) and copy them (e.g: libstdc++.so.6) from your build system to somewhere on your target system (e.g: /mylibs). Point your app here (e.g: using patchelf's --rpath and --interpreter). Your app should run (test it!). If not, it's likely that your glibc is incompatible with the older kernel. You can solve this by recompiling the required version of glibc to support the older kernel - using the --enable-kernel=<version> ./configure switch. If your required version of glibc doesn't support that kernel version then you can supply the missing functions in .so's and load them with LD_PRELOAD.
Generated an executable on Linux 32-bit Ubuntu 11 and tested it on a 32-bit Ubuntu 10 and it failed with a "GLIBC_2.15" not found.
Cyrhon FAQ section says:
Under Linux, I get runtime dynamic linker errors, related to libc. What should I do? The executable that PyInstaller builds is not
fully static, in that it still depends on the system libc. Under
Linux, the ABI of GLIBC is backward compatible, but not forward
compatible. So if you link against a newer GLIBC, you can't run the
resulting executable on an older system. The supplied binary
bootloader should work with older GLIBC. However, the libpython.so and
other dynamic libraries still depends on the newer GLIBC. The solution
is to compile the Python interpreter with its modules (and also
probably bootloader) on the oldest system you have around, so that it
gets linked with the oldest version of GLIBC.
and
How to get recent Python environment working on old Linux distribution? The issue is that Python and its modules has to be
compiled against older GLIBC. Another issue is that you probably want
to use latest Python features and on old Linux distributions there is
only available really old Python version (e.g. on Centos 5 is
available Python 2.4).
I'm building a large C++ project using cmake on ubuntu 12.04 and then taking the resulting binary package and trying to run it on ubuntu 11.04. However the program fails saying it needs glibc version 2.14 but can only find up to version 2.13.
How can I find out exactly why glibc=>2.14 is required?
Unlike most libraries, glibc versions its symbols. Every symbol is tagged with a value (e.g. "GLIBC_2.3.4") representing the version of the library where it's interface was last changed. This allows the library to contain more than one version of a given symbol and support binaries compiled against older versions while preserving the ability to evolve. You can see this detail with objdump -T /lib/libc.so.6.
Basically, something in your app was linked against a symbol that was changed since 11.04. Try objdump -T on your binary and see what tags it's looking for.
But broadly, backwards compatibility doesn't work like that in Linux. If you want something to run on older software, you should build it on older software. It's possible to set up a backwards-compatible toolchain on more recent distros, but it's not the default.
When you build your C++ project, it will link to the version of the glibc library on your 12.04 installation. What are the linker options in your build command?
Without knowing exactly what you are building, I'd say you might be better off building on 11.04 and then running on 12.04.