GCC upgrade and shared libraries - macos

I'm on Mac OS X 10.9 Mavericks with command line tools installed, so I got clang-500.2.79. However, some software does not build with clang, hence I want to install GCC. So I got a question about GCC, specifically what will happen later when if I decide to upgrade GCC.
Suppose I install current version of GCC in /usr/gcc-4.8.2. Suppose I also use this gcc to build and install some software on my system that links against shared libraries in /usr/gcc-4.8.2/lib (in addition to system libraries in /usr/lib).
Suppose also I later decide to upgrade GCC to say version 4.9 and install it in /usr/gcc-4.9 and remove the old version in /usr/gcc-4.8.2.
Will the software that linked against shared libraries in /usr/gcc-4.8.2/lib continue to work i.e. will it magically (libtool?) find shared libraries in /usr/gcc-4.9 now? Or will everything I ever built with gcc-4.8.2 have to be recompiled after gcc upgrade?

Related

Is it possible to use a different gcc version inside a Conda environment?

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).

Does it matter that I update the gcc 4.6 to 4.7 or higher in Ubuntu 12.04(LTS)

I found that more and more open source libraries will use C++11 features, and my Ubuntu Desktop 12.04 just has gcc 4.6, I want to use the update-alternatives to change the default gcc version into 4.7 or 4.8. I wonder that, if the libraries in the /usr/local/lib compiled by gcc 4.6 will need to be recompiled by the new gcc 4.7/4.8. In my opinion, if the dependency libraries are still in the system, there is no need to recompile. But, If one dependency library compiled by the new gcc 4.7, is the dependency among libraries still right? Sorry for my poor English.
Thanks.
Just update to 13.04 (and soon 13.10). From my 13.04 development box:
edd#max:~$ ls -1 /usr/bin/g*-4.*
/usr/bin/g++-4.4
/usr/bin/g++-4.5
/usr/bin/g++-4.6
/usr/bin/g++-4.7
/usr/bin/gcc-4.4
/usr/bin/gcc-4.5
/usr/bin/gcc-4.6
/usr/bin/gcc-4.7
/usr/bin/gcc-ar-4.7
/usr/bin/gcc-nm-4.7
/usr/bin/gcc-ranlib-4.7
/usr/bin/gcov-4.4
/usr/bin/gcov-4.5
/usr/bin/gcov-4.6
/usr/bin/gcov-4.7
/usr/bin/gfortran-4.4
/usr/bin/gfortran-4.5
/usr/bin/gfortran-4.6
/usr/bin/gfortran-4.7
edd#max:~$
Make sure you upgrade one-by-one and not in jumps. It usually a very smooth process.

How to compile for legacy os

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).

Obtaining GCC for OSX with Developer Tools installed

I want to start working with C++0x. I see that GCC 4.7 has a fair amount of functionality available. I already have XCode 3.2 installed in /Developer
I downloaded: http://fileboar.com/gcc/snapshots/LATEST-4.7/gcc-4.7-20110528.tar.bz2
Can I somehow compile this in /opt/gcc-4.7? How do I then work with my path so I can compile with GCC 4.7 from the command-line but have OSX use the version it needs?
OSX does not need gcc to run - the Developer tools are optional. So you only need to choose between gcc's when you compile. In Xcode you chose explicitly the gcc andin Makefiles you can set $(CC) or similar to the full path.
Alternatively rename the gcc-4.7 gcc to gcc-4.7 and use that so gcc is always the Apple one.
For ease of using multiple C++ compilers I use macports (or fink or homebrew) which will compile the compilers with the correct patches and also has a port select command to switch between the C++ compilers

How can I easily install arm-elf-gcc on OS X?

Please let me know if this should be on Server Fault...
I've got some code I want to compile which requires arm-elf-gcc. I'm not an embedded programmer, so all this is new to me. My development machine is a Mac and I use fink pretty often, so I'd love to be able to install it that way. However, fink doesn't know of any package with that name. I see that gnuarm.org has some binaries for OS X but their packages seem to also include a bunch of stuff (e.g. gcc) I already have. Am I correct in believing that I need to install binutils, newlib and a file called t-arm-elf?
MacPorts supports arm-elf-gcc.
$ port search arm-elf
arm-elf-binutils #2.20.51.0.2 (cross, devel)
FSF Binutils for arm-elf cross development
arm-elf-gcc #4.3.2 (cross, devel)
gcc cross-compilers for arm-elf, with newlib runtime library.
arm-elf-gcc3 #3.4.6 (cross, devel)
gcc 3.x cross-compilers for arm-elf, with newlib runtime library.
Found 3 ports.
Once you install MacPorts, all it would take is:
$ sudo port install arm-elf-gcc

Resources