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.
Related
I am want to compile linux 5.10.162 with CONFIG_DEBUG_INFO_BTF=y, the end goal being to enable bpf CO-RE. However, the build is failing with:
+ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
FAILED unresolved symbol udp_sock
I first thought it was something similar to this issue, but after moving to a newer gcc, the issue persists.
Relevant packages:
gcc 11.1.0 (also tested with 10.2)
dwarves 1.24 (also tested with 1.22)
Bear in mind don't have much experience compiling linux. Let me know if the config will be of use.
We have a project that was working fine in Red Hat Enterprise Linux Server release 6.2. Since GCC version is getting updated periodically, we wanted to have our project to be independent of GCC upgrade in local system. Hence we wanted to keep GCC toolchain (binaries and libraries) in our project rather than standard location in the machine. ldd of our binaries generated out of our project should depend on the libraries in my our project not from the gcc libraries available in local system (because it might change at any time).
How do I do that? Where I shall get specific GCC toolchain for intel 64 bit (C & C++ compilers) ?
Current GCC Version: gcc-4.4.6-3.el6.x86_64
This is a follow up Q to CUDA incompatible with my gcc version.
I've recently updated to Ubuntu 12.04 as well as grabbing the latest CUDA toolkit. My nvcc --version is showing: Cuda compilation tools, release 5.0 (My driver ver is 304.43.)
I'm trying to fix my build environment. I get errs about using GCC 4.6. I can probably fix this w/ the help of the above link. I'm wondering about the other 8 packages in this large project. Should I be concerned with building other pieces with one version of GCC-4.6 and my cuda stuff with GCC-4.5? I figure they should all be compatible, but I've never run into this before. Is this anything I need to be concerned with?
I have run into incompatibility issues with different versions of GCC.
Specifically, GCC 4.7 and 4.6. My Qt applications wouldn't compile for me, because I was using GCC 4.7, and the library was compiled against GCC 4.6. They compiled fine, and there seemed to be no problem at first. But then I ran into trouble actually running them.
I would recommend against using different versions of GCC in the same project.
I am using Cent OS 5.
It has legacy package installed.
With what version of gcc should I compile ?
Does it really required to compile with old gcc version to support old linux os ?
if yes why ?
I'm going to start off by saying that the easiest way to get software builds that will work on CentOS 4, or even older, is to build the code on those target distributions, or ship your code with some scripts/tools to make it easy to recreate a build on that machine. If you've ever downloaded a source code release, and did the /.configure && make && make install steps, this is what I'm talking about.
Those source releases are built upon the GNU Autotools system, which gives you auto-configuration (it determines what can and can't be used on the target system) and generates a makefile to build with.
There are alternatives to the GNU Autotools system (which, frankly, I find a chore to learn and use), like cmake and scons. Here is a page (on scons) which compares the popular build tools:
http://www.scons.org/wiki/SconsVsOtherBuildTools
So what if you still want to build on your CentOS 5 machine for older CentOS installs?
Now for why you do need legacy libraries and compilers to build with, if you want to build on your CentOS 5 system:
So you have CentOS 5, which runs this toolchain:
gcc 4.1.2
glibc 2.5.x
libstdc++ 4.1.2
And CentOS 4, which runs this toolchain:
gcc 3.4.x
glibc 2.3.x
libstdc++ 3.4.x
The big problem is that if you were to just build C or C++ software with the standard CentOS 5 tools, they would be linked to the CentOS 5 C and C++ libraries (glibc, libstdc++, libgcc), and these libraries are not backward compatible with older releases. That is, software built for glibc 2.5.5 is in no way guaranteed to run with glibc 2.4, or even glibc 2.5.4 (though unless there are special circumstances, you would be able to run glibc 2.4-built software on glibc 2.5.x). You will also need to build the dependencies against the older library versions.
When you go even older, you will need to build a cross-compiler (look up crosstool) that will allow you to target builds for older systems, that will link to the older versions of libc and other dependencies built against that as well.
Is there something else besides building on the target and such?
You could static link all your dependencies into the binary, so you wouldn't have to worry about the dependencies and such. However, I have never done such a thing and I forget if there was some problem to linking glibc statically, or if I'm thinking of some other major library that posed issues with static linking (on a technical level).
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.