I am trying to find out which version of OpenMP is installed on my machine. It's a Linux box I am connected to using ssh.
I am using gcc to compile using -fopenmp.
Quoting from the GCC wiki page containing information on the OpenMP specification:
As of GCC 4.2, the compiler implements version 2.5 of the OpenMP
specification, as of 4.4 it implements version 3.0 and since GCC 4.7
it supports the OpenMP 3.1 specification. GCC 4.9 supports OpenMP 4.0
with the follow exceptions (as of 2013-11-28): the new 4.0 directives are not yet supported in Fortran and omp target will always run on the host
With gcc, I suppose you should be looking for the compiler version
gcc -v
Perhaps in combination with the version of libgomp
ls -ltr /usr/lib/libgomp.so.1*
e.g.
-rw-r--r-- 1 root root 46652 2010-09-27 23:00 /usr/lib/libgomp.so.1.0.0
Depending on your distro this might give more info:
dpkg --status libgomp
E.g:
Package: libgomp1
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 84
Maintainer: Ubuntu Core developers <ubuntu-devel-discuss#lists.ubuntu.com>
Architecture: i386
Source: gcc-4.5
Version: 4.5.1-7ubuntu2
Depends: gcc-4.5-base (= 4.5.1-7ubuntu2), libc6 (>= 2.6)
Description: GCC OpenMP (GOMP) support library
GOMP is an implementation of OpenMP for the C, C++, and Fortran 95 compilers
in the GNU Compiler Collection.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <debian-gcc#lists.debian.org>
In my case it confirms that the version matches gcc
Related
I have MSYS2 64 bit installed in my system.
When I try to check the gcc version, I am getting the following output.
$ gcc --version
gcc.exe (Rev9, Built by MSYS2 project) 10.2.0
Copyright (C) 2020 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.
But I want to use a specific mingw version for my project which uses qt library.
When I check my build log and installation folder of my qt project I found this.
|Project name: DataManager
|Project version: undefined
|C++ compiler for the host machine: ccache c++ (gcc 4.9.2 "c++ (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 4.9.2")
|C++ linker for the host machine: c++ ld.bfd 2.24
|Program python3 found: YES
|Found qmake: C:\Qt\5.6.3\mingw49_32\bin\qmake.EXE (5.6.3)
I am assuming that it uses mingw49_32 version and gcc version 4.9.2.
I would like to use the same gcc version (4.9.2) in MSYS2.
How can I achieve it ?
You can't do that with MSYS2. Old packages are eventually removed from MSYS2 repos, so even if it had GCC 4.9 at some point in the past, it no longer does. The earliest available version is GCC 9.3.
Even if it was in the repo, you'd have to manually download and install it and all its dependencies, since there's no way to download outdated packages directly from pacman.
But, I suspect that:
You already have GCC 4.9 installed in C:\Qt\5.6.3\mingw49_32\bin.
Even if you don't, you might be able to get away with using an up-to-date GCC.
I have a bunch of libraries built in RHEL 7 using gcc 4.7. Is the following possible
1) Can the binary be executed in RHEL 6 host without re-compiling ?
2) The shared objects produced in RHEL 7 hosts with gcc 4.7 be used
on a RHEL 6 with gcc 4.4 compiler ?
What are the caveats here ?
If you won't link your binary statically, your problem would be shared libraries:
gcc usually links C programs with:
glibc -- implementation for C runtime library. RHEL 6 and 7 have different versions of that library. glibc uses symbol tagging, i.e.:
myaut#panther:/tmp> readelf -s /lib64/libc.so.6 | grep ' open#'
1679: 00000000000d8a70 90 FUNC WEAK DEFAULT 12 open##GLIBC_2.2.5
So if your program with link with function which has newer tag that is present in RHEL6, you won't be able to run your program.
libgcc_s is a GCC runtime that mostly contains functions that are not available on hardware platform (i.e. 32-bit binaries doesn't support 64-bit long long arithmetic, so they require library to do that), put it seem to be optional.
Finally, GCC 4.4 and 4.7 have compatible ABIs, so you shouldn't run into trouble due to different compilers.
If you use the GCC compiler included with the Red Hat Developer Toolset, RH guarantees that an app compiled on a major RHEL version will also run on the +1 version, e.g compile on RHEL 6 and run on either RHEL 6 or 7.
There's v4, but also GCC 5 and working on 6.
See http://developers.redhat.com/products/developertoolset/overview/
I have a c++11 library ( https://github.com/matiu2/cdnalizer ). I want to distribute it on centos6 and ubuntu12.04 LTS.
It compiles happily on Ubuntu 13.10 and Gentoo.
I tried compiling with as much staticness as I could, but it still depends on a glibc that centos doesn't have:
matiu#matiu-laptop:~/projects/cdnalizer/build/src/apache$ readelf -d mod_cdnalizer.so | grep NEED
0x0000000000000001 (NEEDED) Shared library: [libapr-1.so.0]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000006ffffffe (VERNEED) 0xd520
0x000000006fffffff (VERNEEDNUM) 3
build line:
/usr/bin/g++ -fPIC -I/usr/local/include -I/usr/include -I/usr/include/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/c++/4.8 -Wall -Wextra -g -shared -Wl,-soname,mod_cdnalizer.so -o mod_cdnalizer.so CMakeFiles/mod_cdnalizer.dir/mod_cdnalizer.cpp.o CMakeFiles/mod_cdnalizer.dir/config.cpp.o CMakeFiles/mod_cdnalizer.dir/filter.cpp.o ../libbase.a -lapr-1
I have tried compiling gcc-4.8.2 on centos, but the binaries it produces have similar glibc dependencies:
[root#matt src]# ./test_config
./test_config: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test_config)
./test_config: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./test_config)
I heard that you can't escape glibc dependencies for shared libraries because c++ throws excoptions and so needs the shared libstdc++ (but my lib doesn't throw exceptions across the library boundary).
I also heard that you can't link in glibc statically because the static lib was not compiled with -fPIC.
My main question is:
How can I distribute my c++11 shared library on centos6 ?
My sub questions are:
Can I compile a c++11 shared library on ubuntu 13.10, and have it load on centos6 (and older ubuntus) ? how ?
Can I compile a c++11 shared library on centos6 and have it work on standard centos installs ?
(Don't worry about Apache2.2 vs 2.4 dependency .. that's the easy bit)
Can I compile a c++11 shared library on centos6 and have it work on standard centos installs ?
If you can't build your code with the standard CentOS 6 g++/glibc/libstdc++, then no, it's not going to run on standard CentOS 6 installs.
The CentOS distro is for long term support (LTS). Critical bugs get fixed with updates, but software otherwise doesn't change, usually. This is a feature. Even with 3rd party repositories (e.g. EPEL), the available software for CentOS isn't really recent.
Can I compile a c++11 shared library on ubuntu 13.10, and have it load on centos6 (and older ubuntus) ? how ?
If you can compile it using the g++ 4.4 toolchain, sure. In this case, you cannot use a more advanced compiler. A quick search on Ubuntu's 12.04 LTS package list shows libstdc++6-4.5-dbg using a version of libstdc++.so.6 which would be backward incompatible, based on error messages above.
How can I distribute my c++11 shared library on centos6 ?
As you've shown above, you'll have at least one updated dependency (libstdc++.so.6) that you'll need to ship with your library, and install in some odd location, with it's attendant headaches (LD_LIBRARY_PATH, what happens to any other C++ plugins, etc.). And update at some point.
Some enterprise users would object to something like this, mainly because it doesn't mesh well with the existing OS.
Statically linking in dependencies (like in Ali's answer with the Developer Toolset below) could work also. It's also not without problems (updates to dependencies again), but might be the best chance for your code to work on CentOS 6.
I see from comments to Ali's answer, that devtools 1 (gcc 4.7.0) didn't work, making it unlikely that devtools 1.1 would work. So it seems you do need C++11 support up to the level of gcc 4.8 in this case.
Your problem has nothing to do with GLIBC.
Your problem is that libstdc++.so.6 on the CentOS6 is too old.
According to distrowatch, CentOS 6.5 shipped with GCC 4.4.7. C++11 support was mostly complete in GCC 4.8, and in 4.4 had only incomplete support.
If you can build your library with GCC 4.4.7, then it should work (provided you build it on an old enough system). If you can't, then you'll have to update GCC on your target CentOS system.
Alternatively, you can distribute a newer version of libstdc++.so.6 (one from GCC 4.8), install it in non-default location, and ask your customers to link against that newer version (either via LD_LIBRARY_PATH, or better by supplying appropriate -Wl,-rpath=... option at link time).
In short:
Things are only backward compatible. You need to pick the oldest
release of the distro you want to support and build on
that. The later releases of that distro will most likely be backward
compatible so your shared library will do just fine on later releases.
You either need to build the compiler with C++11 support from source or install it from some repo of the distro. Prefer the latter if possible due to compatibility issues.
Any non-system library should be statically linked into your shared
library: -Wl,--static -lmylib1 -lmylib2 -Wl,--dynamic. The important here is that -Wl,--dynamic is at the end, after all statically linked stuff.
I haven't tried it myself but my colleague who does this routinely says:
Use CentOS 6.5 (the latest of the 6.x versions as of writing).
Install devtools / Developer Toolset. The compatibility issues are supposed to be resolved by special, patched version of the developer tools. Developer Toolset 2.1 Beta comes with gcc 4.8.
Link statically all third party libraries and libstdc++. However, do not
link glibc and other system libraries statically that are supposed to be on the target machine
anyway.
The programs that my colleague compiles this way work on my Ubuntu machine just fine. (He uses CentOS 5.10, which seems to be the oldest, still supported distro that has glibc 2.5.)
Hope this helps.
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.
I will like to install GHC 7.2.2 on a Redhat x86_64 (RHEL v5) server at work (in my user account. I don't have root access). I downloaded the generic binary for Linux x86_64 from GHC download page. But, when I run configure, it throws glibc version exception for ghc-pwd since the glibc version on Linux is 2.6. The required glibc version is 2.7.
I googled around but didn't find any pre-configured GHC binaries for Redhat 5. I will appreciate pointers on how to work around the glibc version issue if any one has figured it out for RHEL 5 (or any Linux flavor if the workaround is general). Alternatively, if there are zipped binaries for Redhat x86_64 available somewhere, I can download and unzip them, if you point me to them. Otherwise it looks like I am stuck with GHC 6.12 at work.
I built ghc 7.4.1 on stock RHEL 5.3, by starting with a binary build of ghc 6.6 or 6.8 (forget which one) which ran fine on the platform. Then I used that to build ghc 6.12 from source, and then used 6.12 to build 7.4.1 from source. Had to use gcc 4.3 to build 7.4.1, but that's fine as gcc 4.3 is available on RHEL 5.3.
It's not much work, just a fair amount of time for all the builds to complete.
I had a similar problem, so I compile ghc myself. Doing so is non-trivial because you need newer binutils and gcc. But t can be done (all in user-land).
GHC needs a GHC binary available to compile itself. There are precompiled GHC binaries available, but they have been built against newer glibc versions
RHEL 5 has glibc 2.5, so you can use GHC 6.8 and bootstrap from there. Generally GHC can be bootstrapped with $VERSION-2 or newer (the precise version is documented with the source downloads).
You will also need a newer version of gcc. #alex-iliev suggests that gcc 4.3 is sufficient, which is available on RHEL 5. Your alternative is to use Gentoo Prefix to install an up-to-date gcc.
Download and install the precompiled 6.8 in a directory:
wget http://www.haskell.org/ghc/dist/6.8.3/ghc-6.8.3-x86_64-unknown-linux.tar.bz2
bunzip2 ghc-6.8.3-x86_64-unknown-linux.tar.bz2
tar -xf ghc-6.8.3-x86_64-unknown-linux.tar
cd ghc-6.8.3
mkdir ~/ghc_bootstrap_6_8
./configure --prefix=/home/wilfred/ghc_bootstrap_6_8/
make install
Compile 6.12:
wget http://www.haskell.org/ghc/dist/6.12.3/ghc-6.12.3-src.tar.bz2
bunzip2 ghc-6.12.3-src.tar.bz2
tar -xf ghc-6.12.3-src.tar
cd ghc-6.12.3
mkdir ~/ghc_bootstrap_6_12
PATH=/home/wilfred/ghc_bootstrap_6_8/bin:$PATH ./configure --prefix=/home/wilfred/ghc_bootstrap_6_12/
make
make install
Compiling 7.2 and 7.6 is the same process as 6.12. Compiling can take several hours so you may want to look at quick builds (although you'll want a normal build for the final GHC version).
If you do go down the Gentoo Prefix root, just bootstrap your way to GHC 7.2. You can then modify $EPREFIX/usr/portage/eclass/ghc-package.eclass to add the line:
PATH=/home/wilfred/ghc_bootstrap_7_2/bin:$PATH
then simply add ghcbootstrap to your USE flags and:
emerge --nodeps ghc
Its ghc 6.8 to compile 6.12 from source