I have downloaded gcc binaries (gcc-4.8.2-16.el7.x86_64.rpm). i extracted (it created a directory usr) and checked the version of
gcc using
usr/bin/x86_64-redhat-linux-gcc -dumpversion
It says it as 4.4.6. But it should have been 4.8.2. right. I tried downloading 4.8.2 rpm from different mirrors but "dumpversion" is not showing right version.
Can you please let me know the reason and also tell me how to download the 4.8.2 gcc.?
The "dumped" version number is correct, that you can be sure of.
The path that you query is very odd. Normally it should be gcc, x86_64-linux-gnu-gcc or something similar.¹
And GCC always has a variant with the explicit version number, so try gcc-4.8 or x86_64-linux-gnu-gcc-4.8.
1) But Redhat is known to invent their own rules ...
Related
I'm currently compiling sources using --coverage, with GCC. The generated .gcno files (and the instrumented libraries) are to be packed in a RPM and the code coverage evaluated on another, target platform.
Now, I'm having a problem getting the coverage data, because when I run the programs calling the instrumented code, I get messages telling me that I have a version mismatch. They look like:
".gcda:Version mismatch - expected A85R got B12R"
Now, I've seen this question: GCOV Version mismatch - expected 700e got 408R which says I must use the same toolchain when compiling and when executing the code.
I'm compiling using gcc 11.2.1, and gcov --version says the same thing, on the source platform.
On the target platform, gcc --version and gcov --version both give that very same version number.
The compiling and the testing is done on the same "physical" machine, but on different Docker containers. On both of them, the GCC version and gcov version are the same
I've done further testing: even on the Docker container where we compile, we cannot run the coverage, and get the same error. Or, to be more precise, when compiled using gcc 11, it will say "version mismatch". However, when compiled using gcc 8.5, it works.
The setup is that we have the GCC 11 toolset, which requires gcc 8.5 to install. By default, gcc 8.5 is enabled, and you have to use a script (provided by the gcc 11 toolset) to enable the later. That script updates different variables, like the PATH, LIBRARY_PATH, etc., to look at GCC 11 first.
However, I'm pretty sure it doesn't upgrade the libc.so library, and that it's the cause of the problem: I compiled two of our simplest libs (each of them having no dependencies whatsoever, except libc) with gcc 11, in coverage mode. Then I compiled a simple test program, without coverage, calling some functions from the two instrumented libs. I checked (with elfread -d), the program only links to these two libs (and libc).
Calling this test program while on the compilation container results in the Version mismatch error, which would lead me to conclude that our libc.so isn't compatible with gcc 11.
I wonder if there is a way to get a "native" gcc 11, instead of a "toolkit" package which has to be installed over a gcc 8.5 (my colleague in charge of creating the Docker containers tells me that for gcc 9 and above, there are only "toolkit" packages, requiring gcc 8.5 to install).
Our target architecture runs on Rocky Linux, and I think our development architecture is a Redhat, if it has any importance here.
When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)
After upgrading from Fedora 25 to 26 the default gcc version is now version 7.1.1 and the output of gcc -dumpversion has changed from major.minor.patch to just major.
new output:
$ gcc -dumpversion
7
The manual states
-dumpversion
Print the compiler version (for example, 3.0, 6.3.0 or 7)—and don’t do
anything else. This is the compiler version used in filesystem paths,
specs, can be depending on how the compiler has been configured just a
single number (major version), two numbers separated by dot (major and
minor version) or three numbers separated by dots (major, minor and
patchlevel version).
I have not found where to change this compiler configuration to include the three numbers configured with dots. The closest I have found is the major version only configuration:
--with-gcc-major-version-only Specifies that GCC should use only the major number rather than major.minor.patchlevel in filesystem paths.
I used both options together:
gcc -dumpfullversion -dumpversion
This seems to work on old and new in a uniform way:
[root#zeta ~]# gcc -dumpfullversion -dumpversion
4.4.7
[jenkins#build-el7 ~]$ gcc -dumpfullversion -dumpversion
7.2.1
So after some research I found the configure the version is a compile time option (if you compile the compiler from source).
I also found that there is a new gcc -dumpfullversion option that will provide the full version number, ie 7.1.1 which is what our build system expects. Small caveat is that -dumpfullversion is not supported on older versions of gcc.
So we had to change the build system to get the version via gcc -dumpversion and check if its a single digit and if so then substitute -dumpfullversion to get the full major.minor.patch gcc version.
I have been using gcc version 5.3.0. It says that it comes with openmp support. But every time when I compile a program using either gcc [by terminal] or via xCode 7, I get same error, "file omp.h not found". I have searched too much on this issue and tried almost everything I found.
First I tried to locate omp.h on my mac. I found some files; then in header file, I used that specific location of omp.h but no help [it gave me linker error].
I installed gcc version 6.0 (pre-release) but no help. I tried changing C_INCLUDE_PATH [which is now, and previously set to none] but that didn't helped me as well.
I reinstalled clang-omp but no help.
I am using llvm compiler version 7.0. Although i have installed clang-omp, there is no omp.h in my /usr/include/*
I changed the compiler and now I am able to run it. [It was issue of clang, which I couldn't solve].
I am a student and Intel is giving Intel Parallel Studio 1 year licence for free to students.
So I downloaded, and installed it.
In xCode, under build settings, I set my compiler to 'Intel C/C++ compiler' and in parallalization, I turned it to 'yes'. That was it. Then it compiled successfully. But, note that you won't be using header file 'omp.h' anymore.
By the way, I am still looking for answers, just to know what I was doing wrong.
You can install 'clang-omp' or 'gcc' (corresponds to GCC 5.3 right now) packages via Homebrew, both of which support OpenMP.
The built in GCC is based upon GCC 4.2.1 abs uses LLVM back end via Dragonegg, which is why it doesn't support OpenMP.
As noted already, Intel compilers support OpenMP on Mac.
I don't use Xcode editor so I don't know how to use any of these from there, but all will work from terminal just as they do on Linux.
the compiler on the mac is clang (based on llvm 3.5) which does not support openmp.
you can try install llvm/clang/openmp from source or using prebuild binaries, but I must admit it does not work as advertised for me…
edit unless you use the -fopenmp=libomp flag.
On my Linux platform, I have several versions of gcc.
Under usr/bin I have:
gcc34
gcc44
gcc
Here are some outputs:
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
$ gcc44 --version
gcc44 (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6)
I need to use the 4.4 version of gcc however the default seems to the 4.1 one.
I there a way to replace /usr/bin/gcc and make gcc44 the default compiler not using a symlink to /usr/bin/gcc44 ?
The reason why I can't use a symlink is because my code will have to be shipped in a RPM package using mock. mock creates a minimal linux installation from scratch and just install the specified dependencies before compiling my code in it. I cannot customize this "minimal installation".
Ideally, the perfect solution would be to install an official RPM package that replaces gcc with gcc44 as the default compiler. Is there such a package ? Is this even possible/good ?
Additional information
I have to use SCons (a make alternative) and it doesn't let me specify the binary to use for gcc.
I will also accept any answer that will tell me how to specify the gcc binary in my SConstruct file.
One way is to compile and install gcc from source.
See http://old.nabble.com/Choosing-compiler-td4675207.html
From that:
env = Environment()
env.Replace(CC = "my_cc_compiler")
Or, as per the answer to this question,
env['CC'] = 'gcc44'
This is a long way in the past now, but I just thought I'd add the solution I found, which doesn't require changing the SConscript file. It was useful for me as I need to build v8 under centos 5, so possibly it may be useful for someone else too.
CC=gcc44 CXX=g++44 scons
That's it!