macOS Latest XCode 3.2.1 comes with an old GCC (4.0.1)

[jtibbitt]

The latest XCode (3.2.1) comes with GCC version 4.0.1, but from what I see:

http://hpc.sourceforge.net/

the latest GCC is 4.4.0. The GCC that comes with XCode is located in /usr/bin. If I install this latest version of GCC using the suggested method, it puts in all in /usr/local/bin. So then I have two versions. Is there anything wrong with deleting /usr/bin/gcc, /usr/bin/g++ and /usr/bin/cpp and just using the newer versions?

Jeff

 

[Catfish_Man]

It also includes GCC 4.2 and LLVM-GCC 4.2, all three from Apple's GCC branches. It looks like newer versions are probably not going to happen due to GPL3, all the attention is focused on clang now.

Installing a newer GCC should work fine, though it may not have some Apple-specific changes.

 

[gnasher729]

The latest XCode (3.2.1) comes with GCC version 4.0.1, but from what I see:

http://hpc.sourceforge.net/

the latest GCC is 4.4.0. The GCC that comes with XCode is located in /usr/bin. If I install this latest version of GCC using the suggested method, it puts in all in /usr/local/bin. So then I have two versions. Is there anything wrong with deleting /usr/bin/gcc, /usr/bin/g++ and /usr/bin/cpp and just using the newer versions?

Jeff

1. XCode comes with newer versions.
2. The versions that come with XCode may include changes by Apple that are not part of the sourceforge versions.
3. The versions that come with XCode have been tested by Apple and are in constant use by thousands of Mac developers, so any bugs are much more likely to be found.

Basically, you decide whether you want to be a gcc beta tester or a software developer.

 

[jtibbitt]

Ok, good info, thanks.

 

[Krevnik]

It also includes GCC 4.2 and LLVM-GCC 4.2, all three from Apple's GCC branches. It looks like newer versions are probably not going to happen due to GPL3, all the attention is focused on clang now.

Installing a newer GCC should work fine, though it may not have some Apple-specific changes.

This right here is why would should probably not install a new version OVER the Apple version. Apple's builds are from their branches, which all contain tweaks, fixes, etc that the GCC mainline may not get. If Apple doesn't have a branch that applies these fixes to 4.4, then I probably wouldn't use it.

As another FYI: The gcc/g++/etc that you are seeing are usually symlinks. Apple has a tool for selecting which version of GCC is used on the command-line, and as such, you can get into trouble thinking you can overwrite things. Because setting the GCC version will stomp on your installed copy.

 

[gnasher729]

It also includes GCC 4.2 and LLVM-GCC 4.2, all three from Apple's GCC branches. It looks like newer versions are probably not going to happen due to GPL3...

Why would GPL3 be a problem?

 

[Krevnik]

Why would GPL3 be a problem?

GPL3 has a patent clause that wasn't in GPL2. It basically requires that anything that you own a patent on and contribute to free software automatically gets a royalty-free patent license for.

So if I have a patent on process 'foo', and add it to GPL'd product 'bar', 'bar' now has a permanent, irrevocable license to 'foo'.

I believe some large companies are worried about the clause. The wording is such that not just 'bar' gets the license, but all derivative work. So if I contribute patented material to 'bar', and someone comes along and forks 'bar' into a similar, but unrelated product that derives from 'bar', they get a license to my patent as well, without any control on my part.

Considering how much of a legal mire patents are right now, I can see why some might not want to touch that with a ten-foot pole when it wades in and makes it even stickier.

Yes, it doesn't prevent you from suing someone who infringed your software in a non-GPL app, but it really makes the case of infringement against /any/ GPL app tough the moment you contribute to /one/.

I'm thinking clang and LLVM are under a license that makes it easier to keep the two worlds separate.

 

[jtibbitt]

As another FYI: The gcc/g++/etc that you are seeing are usually symlinks. Apple has a tool for selecting which version of GCC is used on the command-line, and as such, you can get into trouble thinking you can overwrite things. Because setting the GCC version will stomp on your installed copy.

Ok, I see the symlinks now:
/usr/bin/cc -> /usr/bin/gcc-4.0
.
.

It's interesting that the default points to gcc-4.0 and not gcc-4.2. Could someone who has XCODE 3.2.1 installed tell me which executibles the following point to:
/usr/bin/g++
/usr/bin/cpp
/usr/bin/gcc

I deleted those links in order to use the gcc, g++ and cpp included with GCC 4.4 from http://hpc.sourceforge.net/ - but all I was really after in the first place was the new gfortran included in that package. And now after reading what is said in this thread, I'd rather switch back to XCODE's default setup for gcc, g++ and cpp, and just use the gfortran standalone compiler from the HPC site.

 

[Krevnik]

It's interesting that the default points to gcc-4.0 and not gcc-4.2. Could someone who has XCODE 3.2.1 installed tell me which executibles the following point to:
/usr/bin/g++
/usr/bin/cpp
/usr/bin/gcc

4.2 is currently marked as 'at your own risk' by Apple. That may change with a later version of the OS.

I deleted those links in order to use the gcc, g++ and cpp included with GCC 4.4 from http://hpc.sourceforge.net/ - but all I was really after in the first place was the new gfortran included in that package. And now after reading what is said in this thread, I'd rather switch back to XCODE's default setup for gcc, g++ and cpp, and just use the gfortran standalone compiler from the HPC site.

You can setup custom compiler settings inside XCode for specific languages, which override what the CLI environment uses. After the package is installed, that should be all you need to do.

If you are using makefiles, you can also specify the GCC version as well (if I recall correctly).

As for reverting, you can do it manually (restore the original symlink once you know where it goes). I personally forget the command that you use to change the default GCC version.

 

[jtibbitt]

4.2 is currently marked as 'at your own risk' by Apple. That may change with a later version of the OS.

In that case, and since the /usr/bin/cc is symlinked to /usr/bin/gcc-4.0, I'm just going to restore the /usr/bin/gcc, /usr/bin/cpp and /usr/bin/g++ symlinks I deleted and point them all to /usr/bin/gcc-4.0.

You can setup custom compiler settings inside XCode for specific languages, which override what the CLI environment uses. After the package is installed, that should be all you need to do.

That sounds very cool. I do not have any experience building programs or software within XCODE yet. Currently, I'm writing small individual programs, subroutines, functions ....etc (using SHELL, FORTRAN, C, TCL ...) and keeping them all within a few library directories. I would like to learn how to take advantage of XCODE's capabilities as a building environment.

 

[jtibbitt]

Actually, looking closer at /usr/bin I see there are:
/usr/bin/g++-4.0 /usr/bin/g++-4.2
/usr/bin/cpp-4.0 /usr/bin/cpp-4.2
/usr/bin/gcc-4.0 /usr/bin/gcc-4.2

I mistakenly thought all three language compilers were tied in with gcc, with code type recognized by file extension. So I'll recreate the symlinks for /usr/bin/gcc, /usr/bin/g++ and /usr/bin/cpp to point to /usr/bin/gcc-4.0, /usr/bin/g++-4.0 and /usr/bin/cpp-4.0, respectively. Can anyone verify this as the default setup for XCODE 3.2.1?

 

[gnasher729]

GPL3 has a patent clause that wasn't in GPL2. It basically requires that anything that you own a patent on and contribute to free software automatically gets a royalty-free patent license for.

So if I have a patent on process 'foo', and add it to GPL'd product 'bar', 'bar' now has a permanent, irrevocable license to 'foo'.

I believe some large companies are worried about the clause. The wording is such that not just 'bar' gets the license, but all derivative work. So if I contribute patented material to 'bar', and someone comes along and forks 'bar' into a similar, but unrelated product that derives from 'bar', they get a license to my patent as well, without any control on my part.

Considering how much of a legal mire patents are right now, I can see why some might not want to touch that with a ten-foot pole when it wades in and makes it even stickier.

Yes, it doesn't prevent you from suing someone who infringed your software in a non-GPL app, but it really makes the case of infringement against /any/ GPL app tough the moment you contribute to /one/.

I'm thinking clang and LLVM are under a license that makes it easier to keep the two worlds separate.

I think not being able to sue GPL software for patent infringement is not something that Apple worries about too much. Microsoft might be in a different situation; they would love to inflict as much damage as possible on Linux (see the current TomTom case). And you would think that nobody would be so stupid and accidentally put code that implements a patent into the gcc compiler.

 

[Catfish_Man]

Personally I think Apple's GPL3 paranoia is misguided, but it does appear to be the case. Not that I really mind in this case, clang looks more promising than GCC anyway .