Thank you for patch. I will try it.

It’s usually quite easy to make stuff which compiles with GCC 4.3 compile with 4.4. Most likely it’s just missing #include statements (look at what functions are undeclared, check what header they come from and add #include at the top of the file, next to its other #include statements).

And in many cases, the fix has already been done by somebody else. For EVA, you will need these 2 patches (cd into the extracted directory and apply the patches with patch -p1 <file.patch):
http://patches.ubuntu.com/by-release/extracted/ubuntu/e/eva/0.4.921+svn42-2ubuntu3/06_fix_ftbfs_with_gcc43.diff
http://patches.ubuntu.com/by-release/extracted/ubuntu/e/eva/0.4.921+svn42-2ubuntu3/09_fix_gcc44.patch
(Note that the first patch is needed even for 4.3, so in fact 4.2 is the last release it wouldn't need patching for.)

Thank you for your comment. “你好” means hello in English. A long time ago, some spammer often sent spam comments to here. I must install a “Some Chinese Please! ” for spam check. So any comments must contain some Chinese words.

I realize that it is a hard work to maintain several compilers and interpreters. Packagers and developers need to test as several times as ever’s. Also, they need to repack some libraries for every version compilers and interpreters. Too many work for them.

Now Fedora has the default GCC version 4.4 and the default Python version 2.6.2. In Fedora 13, Python 3 will get into the repository which are independent with Python 2.6. RPM Fusion also wants to package compat-python25 for the reason that Google GAE SDK requires it.

I just hope that Fedora and RPM Fusion provide some package like compat-gcc-41, compat-gcc-42 and compat-gcc-43. Some softwares I love can not be built on GCC 4.4. They have lost maintenance. I am an ordinary users and I can not know how to write a patch. So it looks unnecessary. I still hope it come true.

And of course, in the case of python, either you have a complex scheme like debian has to manage 3 versions of python, or you use 2/3 packages for every library, which has a huge impact on everybody packaging something using it.

And while you can avoid for noarch rpm to recompile them 2 or 3 times, for compiled module, that’s not possible ( afaik ).

So, IMHO, Fedora should stick to one default version of python and gcc in order to be able to concentrate the effort on them.

The commercial argument is valid ( even if I think that’s outside of Fedora goals to provides support for this ), but what people want to test is not a specific version of gcc but more that the code build on a specific platform. So instead of having 3 versions of gcc, I think people should use chroot or vm.

At least, that’s how I was doing to develop on python in my day job, since the platform we were targetting was debian stable, running python 2.4 and some old version of python-qt.

Also, as far as I know, serious developement shop tend to use buildbot, with specific chroot and os to test build on various os. So no need to have everything in the same distribution, the complexity is not worth the gain, imho.

( 你好 for spam check, but I do not know what it mean :/ )