Best practices in updating GCC and boost on RedHat 7.6 - c++

My setup: Red Hat Enterprise Linux Server release 7.6 (Maipo)
I was previously having a linking problem when trying to link with a boost static library, which i had found out was caused of it being compiled with the C++17 standard with GCC 8.2 but /usr/lib64/libstdc++.so.6 pointing to libstdc++.so.6.0.19. GCC 8.2 was installed from development-toolset8 which I enabled with source /opt/rh/devtoolset-8/enable.
Now my question is what is the best practice way to solve this?( i have read quite a lot on this so i have 2 solution below, more like 1 cause the other one is a glimpse of an idea)
1) I download the package and do the installation from here specifying --enable-shared --prefix=$HOME/gcc (any other options that you think might be useful? ) Do i need to uninstall the dev-toolset8 for this? Then i recompile the boost package with the flag -D_GLIBCXX_USE_CXX11_ABI=1,
2) i try to somehow compile(i have no clue how) the libstdc++.so from the /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++.a (How do i do this? no idea?)
Similar description of my problem which seems to be a:RedHat bug
Thank you

Related

GLIBCXX_3.4.26 Not found

I am trying to build open embedded project. But it shows some error like
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: GLIBCXX_3.4.26 not found
How can i install GLIBCXX_3.4.26 in Ubuntu 16.04 ?
I believe the object you are trying to use was compiled with a fairly recent version of GCC 9 with this bug fixed. This GCC version has not yet been released.
You need to recompile it with the Ubuntu system compiler, or ask the Ubuntu compiler people to backport this fix into the Ubuntu 16.04 system compiler (which seems fairly unlikely to happen at this point).
I solved the problem by 2 steps:
1 Install a Anaconda3
2 Copy the file libstdc++.so.6.0.26 to path '/usr/lib/x86_64-linux-gnu', then create a soft link.
I worte the detail commands here.

Choosing a default gcc/g++ compiler

Im running Matlab on linux (Elementary OS)
The problem im facing is that Matlab isnt compatible with the gcc compiler higher than 4.9.
Same question as: https://www.mathworks.com/matlabcentral/answers/348906-downgrading-gcc-g-for-use-with-mex
When I use "sudo apt get install gcc" 5.4 is automatically installed. When I remove 5.4, Matlab will not recognize 4.9 which I've installed. How do I get Matlab to recognize gcc/g++ 4.9 as my compiler?
I've also followed this but it didnt resolve the problem:
https://www.mathworks.com/matlabcentral/answers/137228-setup-mex-compiler-for-r2014a-for-linux#answer_263109
Any help would be greatly appreciated.
When I remove 5.4, Matlab will not recognize 4.9 which I've installed. How do I get Matlab to recognize gcc/g++ 4.9 as my compiler?
I use Ubuntu (from which you OS is derived) and have had a similar issue. Basically, you can use update-alternative to switch between gcc versions on your choice. Here is a link that explains how to do it.
Here is the documentation on update-alternative, if you need more in-depth knowledge of its functionalities.
Note that uninstalling the default gcc for your distro (5.4 in your case) is no longer required with this solution: you can switch back to it for you development when not using Matlab. You can even install more than two versions of gcc if needed.
Hope this solves your issue.
There is no reason to downgrade GCC for MATLAB.
The reason you run into issues on Linux is because MATLAB installs its own copies of the GCC libraries. If your MEX-files expect newer libraries, they'll fail. You can delete the GCC libraries that come with MATLAB, and it will use the newer ones on your system.
The libraries are at $(MATLABROOT)/sys/os/glnx86 for 32-bit MATLAB, and $(MATLABROOT)/sys/os/glnxa64 for 64-bit MATLAB. $(MATLABROOT) is the installation root for MATLAB.
The files in question are libgcc_s.so*, libstdc++.so* and libg2c.so* (or at least they used to be called like this, I don't have a Linux MATLAB installation here to double-check).
This trick worked for MATLAB 7.0, and still worked a month ago when I suggested this to a colleague.
I do recommend that you rename or move the files, so you can replace them if things go sour.
You will need to restart MATLAB after this change, of course.

mingw upgrade only gdb without changing gcc

I'd like to upgrade my mingw32 gdb from version 7.4 to 7.5 (see reason here). Unfortunately the old gcc 4.6.2 can't be upgraded, because that's the latest tested version for our software (run into issues with 4.8.x). Can anyone suggest a way to do this?
The two programs are totally independent. They share a bit of source code under the hood, but they are on different release schedules and their release tar files don't share anything.
So, there is nothing preventing upgrading gdb while keeping gcc the same -- just rebuild gdb but nothing else.

RedHat devtoolset - implications for distributing compiled code

I'm running CentOS 6.4 and need a later version of the C++ compiler to build my development tools (Qt Creator in this case).
I'm unclear on the implications of using devtools and I'm hoping someone can explain.
If I compile programs using devtools, does that means the executable will run on other Centos 6.4 installations without change?
Or..do I know have to ship libraries or other files with my compiled programs?
If so...do I have to modify my C++ code to reference the later libraries? or is this something done by the person installing my compiled program
I hope this somewhat late answer can still help you. What I found is that compiling my project with devtoolset (1.1 in my case, but that should not matter too much) on RHEL 6.4 produces binaries which can almost run on a standard RedHat EL 6.4 (should be similar for Centos 6.4).
The only trouble I ran into was compiling my project with -std=c++11, which produced some problems due to incompatible symbols. The reason is that the GCC folks considered these parts of the standard library to be experimental in GCC 4.4, so they broke ABI compatibility in some places.
Turns out, there's an easy fix: Link your programs with the additional command-line-argument -static-libstdc++. That way, the binary becomes a bit larger but is runs on an unmodified RHEL 6.4 without installing additional libraries/updates for the devtoolset.
To answer your questions explicitly:
Yes, almost.
No.
Don't change the code, just add -static-libstdc++ when linking.

c : /lib64/libc.so.6: version `GLIBC_2.11' not found (required by c )

I am starting with IGPROF for memory profiling--
i installed it and done all the steps defined in - http://igprof.sourceforge.net/install.html
but when i am running:
c++ -o vvvi-build-and-copy vvvi-build-and-copy.cc -ldl -lpthread
i am getting error-
c++: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by c++)
i google it but not getting what should i do?? i am using ubuntu right now.
Can you help me ?? plz tell me if you need any other info
Thanks in advance....
It usually means that you are using library compiled by newer compiler (gcc) than you are currently running. You need to recompile library with your current compiler or change to newer compiler.
You do not say what version of Ubuntu. Anyway, the problem is caused by a glibc version mismatch between your C++ and the version installed in Ubuntu.
Run the command
/lib/libc.so.6
to get information on your system's glibc, to confirm. You will see something which is not "version 2.11" as your installed C++ requires.
Your situation may occur if you did an incomplete update of the distribution (i.e., glibc is older than C++ expects, because you forced an update to C++ but left glibc behind).
The best solution should be to do an "apt-get upgrade" of the "old" packages ("apt-get upgrade glibc"), or even update the whole distribution.
Note: this probably has nothing to do with igprof installation, which is unlikely to have modified C++, much less glibc.