apple-gcc42: update to 4.2.4

[internetzel]

By merging the official GNU patchsets for gcc 4.2.2, 4.2.3 and 4.2.4 I was able to fix at least two compiler bugs I had when building WebKit. One was a problem with ftree-vrp and the other with mpowerpc64 (64 bit instruction use when optimizing for the G5 and targetting the 32 bit ABI, more and more important nowadays). Both issues were fixed by the update. I'd like to see that merged into this port.

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you provide a patch which keeps this port GPL-2?

[jmroot (Joshua Root)]

The point of this port is to provide the same gcc-4.2 that Apple previously shipped with Xcode, so changing it away from that may not be helpful. Specific bug fixes are probably OK. The full 4.2.2 and later patchsets would of course make it GPLv3.

[internetzel]

It seems (I haven't investigated) that Apple applied all bug fixes that still had happened under GPLv2 and made different fixes for other things (which I replaced with the official fixes). They definitely left out some important ones, which is why it is VERY helpful to merge them. And yes, the port would be GPLv3 then; the patch from gcc 4.2.1 to 4.2.2 changes all license headers to GPLv3.
Other than the licencse change 4.2.2 - 4.2.4 were pure bug fix releases. I browsed all changes and didn't find any new features, apart from some extension to BSD and Solaris support that don't affect Darwin at all.

However maybe one should create another port and deprecate this one in favor of the new one, in a manner that allows to install the original buggy one from Apple but warning the user that there is another one that has more bug fixes applied.

[jeremyhu (Jeremy Huddleston Sequoia)]

apple-gcc42 is provided in order to support corner cases that still need it and no longer have it in Xcode. It's not meant to be a current production compiler. If we were to update it to 4.2.4, would we then provide apple-gcc47 and update it to the latest gcc-4.7.x? I don't see the benefit. I'd rather you just update gcc47 to use the apple driver-driver.

If you are looking for a good production compiler, you should use clang-3.2 or gcc46.

[internetzel]

Not so fast, please.

I already discovered a project that enables me to use the Apple driver-driver with gcc 4.7 . Trying to build WebKit using that I discovered that the missing Xcode headermap support is a problem that already forced me to do heavy changes to the Xcode project files and MANY header files.

After some hours of doing that header stuff and fixing Objective-C/C++ issues I managed to build whole WebKit. Trying to get it working lead me to the conclusion that gcc's OS X ObjC/C++ support while sufficient for firefox is far from being decent and good enough for building a complex AppKit/Cocoa based framework like WebKit - leaving me with gcc 4.2 as the only possible production quality compiler for that purpose.

An updated gcc 4.2 is still needed for building complex ObjC/C++ projects targetting PowerPC OS X.

[internetzel]

Can I really seriously use Clang for targetting PowerPC OS X? Last time I tried it could only compile simple things and observing the development shows that PowerPC ELF support is improving while Mach-O support isn't at the same level. And the PowerPC architecture support itself doesn't seem to have production quality either.

[jeremyhu (Jeremy Huddleston Sequoia)]

I don't see why you feel that updating a compiler that is over 5 years old is the right course of action. Please take this to the macports-dev mailing list, and we can discuss the issue there. This is not the proper forum.

As for clang for powerpc, it is much better now than a few releases ago, but not production. I'm not sure if the 'long double' support was added to 3.2 before the branch or not ...

[internetzel]

I see - this port serves a different purpose than I am using it for. I simply don't want to wait one more year until someone fixes/finishes Clang.

So I'll just provide a fixed build of gcc-4.2 on my project website.

[jeremyhu (Jeremy Huddleston Sequoia)]

If you want to submit a *new* port and be the maintainer for it, that is fine as well.

[internetzel]

Yes, I'd like to! How do I do that?

[internetzel]

I'll follow ​http://guide.macports.org/#project.contributing.new .

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks. You can just use this ticket when ready. Just reopen it and add a comment. You can also get a macports.org account for easier maintainability (svn commit access). Please try to keep the new Portfile whitespace consistent with apple-gcc42, so we can easily apply changes to both if relevant.

Also, it might even be worthwhile to make your new port a subport of apple-gcc42. Take a look at llvm-3.2 as an example of how to make subports. That might make maintenance in the future easier.

Let me know if you need any help.

[internetzel]

Created a subport, but how to make MacPorts aware of its existence?

[internetzel]

selfupdate killed my Portfile...

[internetzel]

Running portindex in /opt/local/var/macports/sources/rsync.macports.org/release/ports did the trick. Is that the way I'm supposed to do it?

[jeremyhu (Jeremy Huddleston Sequoia)]

You should use svn instead of rsync =(

I have the following as my /opt/local/etc/macports/sources.conf

# To enable your local ports repository, uncomment and customize the
# following line to point at your local dports directory
# Example: file:///Users/landonf/misc/MacPorts/dports
#
# To get MacPorts from the www.macports.org rsync server use:
# rsync://rsync.macports.org/release/ports/
file:///Users/jeremy/src/macports/trunk/dports [default]

/Users/jeremy/src/macports/trunk is a checkout of ​https://svn.macports.org/repository/macports/trunk

That way 'port -v sync' doesn't clobber.

Also if you just want to update the portindex, just run 'portindex' from the dports directory.

[internetzel]

add subport apple-gcc42-4.2.4 (conflicting mutually with apple-gcc42)

[internetzel]

Here the patches to add the new subport. I made it mutually exclusive with the main port. Don't know if that might cause problems. It's still a draft.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, if they're going to be mutually exclusive, we might as well just make it a variant. I've made such modifications and am giving the port a quick build test. I'll also put you as maintainer.

[jeremyhu (Jeremy Huddleston Sequoia)]

The build fails for me with:

make[4]: *** No rule to make target `gpl_v3.texi', needed by `doc/gcc.info'.  Stop.

It looks like your patch is missing gpl_v3.texi (and possibly others).

[jeremyhu (Jeremy Huddleston Sequoia)]

Change Portfile to use a +gpl3 variant

[internetzel]

Because I made a diff -ru instead of -Nru it's missing at least gpl_v3.texi . I made a new diff and retrying the build.

[internetzel]

A variant would be much nicer indeed.

[internetzel]

GNU gcc patches 4.2.1 up to 4.2.4

[internetzel]

Port (as subport still) built fine using the latest patchfile (that is I did remove some merge residues from it, .orig files, and didn't rebuild after that).
Now it has to show it can build WebKit. I did rebuild WebKit with all gcc 4.2.4 backend changes applied but didn't yet do it with the C++ frontend patches applied.

[internetzel]

WebKit built and running! So at least for PowerPC code it is doing very well.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, thanks. I'll try to give this another go sometime this weekend.

[jeremyhu (Jeremy Huddleston Sequoia)]

r101200 r101201

Thanks.