My application links to libraries which are built on RHEL 6. When I compile this application on RHEL 7 linker throws errors for glibc version.
Following is one of the error :
undefined reference to symbol '__tls_get_addr##GLIBC_2.12'
/lib64/ld-linux-x86-64.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
For fixing I copied libc and libm from RHEL 6 to RHEL 7 and linked to these along with libc and libm from RHEL 7. Will it cause issue at runtime if I copy libc and libm from RHEL 6 to RHEL 7?
Any other way to get away with such issues?
Thanks,
Mangesh Sawant.
Will it cause issue at runtime if I copy libc and libm from RHEL 6 to RHEL 7?
Copying libc.so.6 and libm.so.6 from RHEL6 to e.g. ~/rhel6/libs or /tmp will not cause any issues (you've already done it).
But overwriting the RHEL7's /lib64/libc.so.6 with RHEL6's copy is likely to make every program on the RHEL7 system to crash, and render that system unbootable. Make sure you have backups and a rescue disk, and know how to use it if you decide to try this.
Any other way to get away with such issues?
Correct way to deal with this is to build with a toolchain that targets desired GLIBC. More info here.
While Red Hat Enterprise Linux 6 came with glibc 2.12, it does not have a __tls_get_addr#GLIBC_2.12 versioned symbol, only __tls_get_addr#GLIBC_2.3. That symbol is also present in later glibc versions.
I don't think the problem you are facing can be solved by downgrading glibc. As Employed Russian said, overwriting the system glibc will make the system unbootable anyway.
Related
I'm using KDE Neon 5.25 and it came with GCC 9 version by default.
Though, when trying to run a file by executing it (./file) it throws me an error:
/usr/lib/libc.so.6: version GLIBC_2.34 not found (required by ./file)
I did some research and also saw that this file was compiled with GCC 12.
So I updated to GCC 12, but the problem persists.
So I updated to GCC 12, but the problem persists.
The problem persists because it has nothing to do with the version of GCC.
The problem is that the binary you are using was built on a system with GLIBC-2.34 (or above) and you are using on a system with GLIBC-2.33 (or below).
You need to get a binary that was built for your distribution.
Alternatively you could try to upgrade your system to newer GLIBC, but this is not recommended -- any mistake will likely render your system unbootable.
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
After hours of research (and tries) on how to install id3lib on Qt (windows), but with no success, I decided to use TagLib's library.
I followed this tutorial to build a compatible version of taglib for Qt but still another problem (full log here):
...
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: Dwarf
Error: found dwarf version '4', this reader only handles version 2 and 3
information.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/crt2.o:crt1.c:(.text+0x1f1):
undefined reference to `__chkstk_ms'
...
In CMake, I did configure > MinGW Makefiles.
Can anyone tell how to fix it?
Environment:
Windows 7 (64-bit);
CMake 2.8.12.1;
TagLib 1.9.1;
GCC 3.4.5;
Qt 5.1.1.
The problem stems from the fact that you are using terribly outdated GCC, while your Qt binaries are most likely built with bleeding-edge GCC (or the one close to it). For instance, as the error message shows, DWARF is outdated in case of your current GCC and is incompatible with the one used by your current Qt. Furthermore, even if it wouldn't, you'd still hit other problems with binary incompatibilities, since you essentially mix compilers with different major version numbers, which is strongly discouraged. Notice, that your problem has nothing to do with CMake at all. You can see it yourself in the error message, i.e. the error is reported by ld, the linker utility from (your outdated) GCC toolchain. To conclude, your only option is to update GCC, ideally exactly to the one which was used to build your current Qt.
I am facing a problem, by code was compiled in gcc version 3.4.6 (RED had Linux) and share library is deployed on some other linux system it has gcc version 4.1.2 . The code is crashing while exiting. I know compiler has nothing to do once the shared library is created. Am i wrong?
If not what other OS features are dependent on execution of shared library as on some of the linux envoirnment my code is crashing while exiting.
The code may depend on a specific version of libc, so you should probably check that.
I am trying to make the ARM toolchain in ubuntu. The way it is specified in http://hri.sourceforge.net/tools/arm-elf-gcc.html
I am getting the following error:
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Unrecognized host system name x86_64-unknown-linux-gnu.
does anybody have idea whats going wrong here.
A Google-search on the "machine `x86_64-unknown' not recognized" error message indicates that this can happen if the config.guess and config.sub files in the program you're building are too old to recognize the machine type for 64-bit linux. I expect that's your problem. You can fix that by replacing the ones in your GCC source tree with newer versions; your system should have some in the /usr/share/libtool directory that will work. Alternately, compile in a 32-bit Linux installation, or with "--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu" configure options.
There are also copies here:
http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub
The real question, though, is: Why you are trying to build a version of the ARM toolchain that's that old? The directions on the site you link to will lead you to download the sources for the 2.95.3 version of GCC -- which was released nearly a decade ago. In GCC terms, that's positively ancient; the latest version is 4.5. It's older than a lot of ARM instruction-set changes, too.
Thus, the right solution to your problem, unless you have some specific need for a 2.95 compiler, is to get a version of GCC that's much more recent.
Also, you'll probably save some pain by not compiling it yourself, unless you particularly want to. There are numerous sources of precompiled cross-compilers; since I work at CodeSourcery, I'll recommend ours (which you can download and use for free):
http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?#template=lite. If you want something equivalent to the compiler on the page you linked to, you probably want the "uClinux" version.