Opened 8 years ago

Closed 8 years ago

#37479 closed update (fixed)

apple-gcc42: update to 4.2.4

Reported by: internetzel Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: apple-gcc42

Description

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.

Attachments (3)

Portfile.patch (5.2 KB) - added by internetzel 8 years ago.
add subport apple-gcc42-4.2.4 (conflicting mutually with apple-gcc42)
Portfile-variant.patch (5.7 KB) - added by jeremyhu (Jeremy Huddleston Sequoia) 8 years ago.
Change Portfile to use a +gpl3 variant
gcc-4.2.1-4.2.4.patch.bz2 (2.7 MB) - added by internetzel 8 years ago.
GNU gcc patches 4.2.1 up to 4.2.4

Change History (32)

comment:1 Changed 8 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to jeremyhu@…
Summary: Update Apple gcc 4.2.1 to 4.2.4apple-gcc42: update to 4.2.4
Version: 2.1.2

comment:2 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:3 Changed 8 years ago by 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.

comment:4 in reply to:  3 Changed 8 years ago by 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.

Last edited 8 years ago by internetzel (previous) (diff)

comment:5 Changed 8 years ago by 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.

Last edited 8 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:6 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: wontfix
Status: newclosed

comment:7 Changed 8 years ago by internetzel

Resolution: wontfix
Status: closedreopened

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.

Last edited 8 years ago by internetzel (previous) (diff)

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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 ...

comment:10 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: wontfix
Status: reopenedclosed

comment:11 in reply to:  9 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:13 in reply to:  12 Changed 8 years ago by internetzel

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

comment:15 Changed 8 years ago by 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.

comment:16 Changed 8 years ago by internetzel

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

comment:17 in reply to:  16 Changed 8 years ago by internetzel

selfupdate killed my Portfile...

comment:18 Changed 8 years ago by 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?

comment:19 Changed 8 years ago by 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.

Changed 8 years ago by internetzel

Attachment: Portfile.patch added

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

comment:20 Changed 8 years ago by internetzel

Resolution: wontfix
Status: closedreopened

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.

Last edited 8 years ago by internetzel (previous) (diff)

comment:21 Changed 8 years ago by 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.

comment:22 Changed 8 years ago by 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).

Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: Portfile-variant.patch added

Change Portfile to use a +gpl3 variant

comment:23 Changed 8 years ago by 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.

comment:24 Changed 8 years ago by internetzel

A variant would be much nicer indeed.

Changed 8 years ago by internetzel

Attachment: gcc-4.2.1-4.2.4.patch.bz2 added

GNU gcc patches 4.2.1 up to 4.2.4

comment:25 Changed 8 years ago by 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.

Last edited 8 years ago by internetzel (previous) (diff)

comment:26 Changed 8 years ago by internetzel

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

comment:27 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:28 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

r101200 r101201

Thanks.

comment:29 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.