[Fink-devel] fink, gcc-4.2 and ppl 0.9
We will have to give some serious consideration to using Apple gcc-4.2 compiler from Xcode = 3.1 shortly. The ppl cvs which will become the next ppl release requires gcc 4.0.3 to build. This means that ppl 0.9 will no longer build against Apple's stock gcc 4.0.1 compiler. It does build fine against the Apple gcc-4.2 compiler in Xcode 3.1. If the FSF gcc developers decide to upgrade the ppl requirement to the upcoming release for building the graphite support in gcc 4.4.0, we will have to build the fink ppl package with Apple's gcc-4.2. This of course means that the gcc44 package will only be available on 10.5 and not 10.4. This also leads to the question of whether we might want to create a 10.5-gcc4.2 branch and start building everything in fink with gcc-4.2. Jack - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jack Howarth wrote: |We will have to give some serious consideration to | using Apple gcc-4.2 compiler from Xcode = 3.1 shortly. | The ppl cvs which will become the next ppl release requires | gcc 4.0.3 to build. This means that ppl 0.9 will no | longer build against Apple's stock gcc 4.0.1 compiler. | It does build fine against the Apple gcc-4.2 compiler in | Xcode 3.1. If the FSF gcc developers decide to upgrade the | ppl requirement to the upcoming release for building the | graphite support in gcc 4.4.0, we will have to build the | fink ppl package with Apple's gcc-4.2. |This of course means that the gcc44 package will only | be available on 10.5 and not 10.4. This also leads to the | question of whether we might want to create a 10.5-gcc4.2 | branch and start building everything in fink with gcc-4.2. I don't see why specific package's need for a newer GCC would mean we have to force all of fink to it. Isn't that the point of having fink versions of gcc so that we don't have to rely on a specific Apple GCC for problem packages? Additionally, are you sure it will really need 4.0.3, since Apple's 4.0.1 is really 4.0.1 + a buttload of patches from later versions of gcc? Having the option of using gcc 4.2 as gcc in Fink by default would be good, of course, but I don't think jumping to forcing everything is a good solution just to solve a few specific package issues. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoGo4Uu+jZtP2Zf4RAp+SAJkBXAN0t162EOA39eG0nv0bnlsw9gCfdf9o OgZwsAqSDqLI74d1xY+Pl6w= =+STq -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
Benjamin, The current Xcode 3.1.1 DP1 can't compile the ppl cvs. The response from the ppl developer was... --- Jack Howarth wrote: The ppl cvs only builds with the newer Apple gcc-4.2 compiler in Xcode 3.1. Under the default gcc 4.0.1 compiler in Xcode 3.1 the build fails with the following compile error... Dear Jack, It is a bug of GCC 4.0.1. The minimum version of GCC to successfully compile and use the CVS HEAD version of the PPL is 4.0.3 (this was not true until a couple of minutes ago: I have just committed a fix). Notice that in the past we identified a miscompilation of the PPL with 4.0.2... so I really would not go below 4.0.3. All the best, Roberto I also recall having one of my bug reports against code generation of the Apple gcc 4.0.1 compiler closed with a comment that the compiler was depreciated or such. I agree that we can just build ppl 0.9 with gcc-4.2 but my point was that this will cause gcc44 to be available only on 10.5. The only alternative would be to leave gcc44 building with ppl 0.9, however, the FSF maintainers have been quite firm that gcc 4.4.0 should build against a known version of ppl to insure consistent code generation. The polyhedral results are certain to be consistent across all arches for a given release of ppl but this isn't certain to be true between releases. Also, using ppl 0.9 (if gcc moves on to ppl 0.9) would open the gcc44 package up to all sorts of unexpected issues (since that combination who likely become untested). We could submit a radar bug report to Apple and hope they fix it for Xcode 3.1.1 but I won't hold my breath. Also we would have to configure in ppl 0.9 to override the new gcc = 4.0.3 requirement. Jack On Mon, Aug 11, 2008 at 12:35:04PM -0400, Benjamin Reed wrote: I don't see why specific package's need for a newer GCC would mean we have to force all of fink to it. Isn't that the point of having fink versions of gcc so that we don't have to rely on a specific Apple GCC for problem packages? Additionally, are you sure it will really need 4.0.3, since Apple's 4.0.1 is really 4.0.1 + a buttload of patches from later versions of gcc? Having the option of using gcc 4.2 as gcc in Fink by default would be good, of course, but I don't think jumping to forcing everything is a good solution just to solve a few specific package issues. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoGo4Uu+jZtP2Zf4RAp+SAJkBXAN0t162EOA39eG0nv0bnlsw9gCfdf9o OgZwsAqSDqLI74d1xY+Pl6w= =+STq -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jack Howarth wrote: |I also recall having one of my bug reports against code | generation of the Apple gcc 4.0.1 compiler closed with a | comment that the compiler was depreciated or such. I agree | that we can just build ppl 0.9 with gcc-4.2 but my point | was that this will cause gcc44 to be available only on 10.5. | The only alternative would be to leave gcc44 building with | ppl 0.9, however, the FSF maintainers have been quite firm | that gcc 4.4.0 should build against a known version of ppl | to insure consistent code generation. The polyhedral results | are certain to be consistent across all arches for a given | release of ppl but this isn't certain to be true between | releases. Also, using ppl 0.9 (if gcc moves on to ppl 0.9) | would open the gcc44 package up to all sorts of unexpected | issues (since that combination who likely become untested). | We could submit a radar bug report to Apple and hope they | fix it for Xcode 3.1.1 but I won't hold my breath. Also we | would have to configure in ppl 0.9 to override the new | gcc = 4.0.3 requirement. As I'm not a compiler guru, I must be missing something. Is PPL something that is part of the GCC build? Googling PPL gives me a million false positives. Otherwise, why can't building ppl depend on fink's gcc42 or gcc43? If it is, can gcc44's build depend on fink's gcc42? It's kind of an ugly bootstrap, but we could at least attempt to make sure binaries of gcc42|gcc43 are available in the bindist to make it easier. It seems kind of crazy to *force* all of fink to update to gcc4.2 (which I'm sure will cause all kinds of compile issues on older packages) just to get gcc44, rather than only saying, gcc44 builddepends xcode = 3.1.1 for the subset of people who are needing to do development with that specific gcc version. I just don't see how gcc44 needing a newer xcode has any bearing on fink as a whole. If you're asking can we have an enhancement for fink to use gcc 4.2 if it's available I think that's a great idea. I just think that it is a completely separate issue from getting gcc44's builddepends available. It's perfectly reasonable for gcc44 to be 10.5-only. If you want to support gcc44 on 10.4, fink is already set up to handle such issues. You have 2 versions of the gcc44 info file, one for 10.4 (with Distribution: 10.4) that uses fink's gcc42 or gcc43 to bootstrap, and one for 10.5 (with Distribution: 10.5) that uses xcode 3.1.1's. - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development Blog: http://www.raccoonfink.com/ Music: http://music.raccoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIoHsLUu+jZtP2Zf4RAqVUAJ4nG9ELC9QKndV+9ajgrr+PWDuIVgCeNgOj Zvxl0CecZ5kOdMRcehRlVqg= =ZFgp -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
Benjamin Reed wrote: [] As I'm not a compiler guru, I must be missing something. Is PPL something that is part of the GCC build? Googling PPL gives me a million false positives. And fink apropos ppl shows nothing called ppl. What *is* ppl? -- Martin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
Martin Costabel wrote: Benjamin Reed wrote: [] As I'm not a compiler guru, I must be missing something. Is PPL something that is part of the GCC build? Googling PPL gives me a million false positives. And fink apropos ppl shows nothing called ppl. What *is* ppl? http://www.cs.unipr.it/ppl/ Peter -- Peter O'Gorman http://pogma.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
On Mon, Aug 11, 2008 at 03:53:47PM -0400, Benjamin Reed wrote: Jack Howarth wrote: | Benjamin, | If it is a 10.5-gcc-4.2 branch, I would assume by default it | would be an opt in. Besides, I would surprised if Apple doesn't switch | the default compiler to gcc-4.2 for Snow Leopard so we will likely | want to do that for 10.6 anyway. Why can't we just create a 10.5-gcc-4.2 | branch, dump unstable over into it and set fink to build with gcc-4.2. | Then fink developers could play with that branch at their leisure. My point is, if we add support for users to opt-in to GCC 4.2 through fink.conf, we don't need a branch! People can continue to use fink just as it is now. People who want the performance update can move to 4.2, and can submit patches with fixes (or bug reports) for packages as-needed. I think it is a bad idea to have another all-or-nothing branch, it was a pain for 3.3-4.0, it was a pain for pangocairo; it's a lot of work, and the only reason to do it was because it was a forced catastrophic change and it was something we couldn't do without a lot of pain for the user in the meantime. Making a branch should be a last resort, not the default. | Also, I don't think performance improvements is a small deal overall. They are not a small deal for *you*. But that guy with an 800Mhz G4 who only uses fink for 2 programs that he runs once a month is not interested in spending 3 days downloading Xcode 3.1.1 and/or compiling a new gcc just to get a performance update he doesn't need or want. Fink has a very *very* wide range of use-cases, and performance is only one of them. This is a very important point. I'd say many/most fink users care little to not-at-all about getting maximum performance nor do they use packages where raw performance is even a really noticeable issue. The common user complaints are about lack of binaries and having to compile even a quick source or do an x11 upgrade that doesn't even require compiling at all, but nobody says why aren't we using -Os everywhere? That latter would be a quick help even without requiring a new compiler or distro-fork. | My instinct is that most everything will build fine that uses recent | upstream sources. Using a gcc-4.3 would be more problematic. If anything | I suspect the biggest effort will be removing any patches added to packages | to build on the older gcc 4.0.1. Again, I'm not saying not to work on making things work with 4.2. Performance is good. I'm all for it. But, Fink's strength has been in making transitions easy for users. Rebuilding everything all at once because we said so is not an easy transition for the users. [...] It should be possible to make patches that continue to work with older gccs, in which case it should not be necessary to do that. 4.2 is ABI-compatible with 4.0.1 binaries, right? I haven't heard anything about ABI incompatibility in 4.0 vs 4.2 vs 4.3 (we alrady mix'n'match them). Portable patches are actually a good idea, because upstream can include them for the future. Again comes back to not *forcing* a new compiler on *everything* just because a handful of other packages want (or maybe need) it. It's no different than building against OSX 10.5.4. It's assumed that if you built fink stuff on 10.5.4, your binaries probably won't work on 10.5.0. Going forward in a binary-compatible way doesn't require revision bumps. Only changing ABI or library compatibility or some such does. Well, we kind-of assume that within a 10.X series it's forward/backward, but again it would be easy to use our normal dependency mechanisms to require at least a certain baseline version of whatever platform or virtual package. In the end, Fink's most precious resource is time. A lot of us don't have time to work on all-or-nothing big projects; look how long it to for pangocairo to get finished, even when a not insignificant number of people were spending many hours on it. It is not a good idea to do a big branch and dump it on everyone at once unless there is no alternative, and in this case, I think there is definitely an alternative. Those who are performance-minded can always opt-in, but it's not worth forcing everyone to do it, when it *also* means forcing maintainers into spending a bunch of time they already don't have on the transition, and forcing users to spend significant time on something they may or may not want. I wish there were stronger words than I completely agree. Fink's primary audience just wants stuff to work with a minimum of time and hassle. Maintainers already have a zillion hoops to jump through and are already being forced to maintain packages for platforms they don't have and accept patches from others here, this fixes X on machine type Y that they don't understand. Forking the distro should *never* be considered until all other approaches have actually been tried and proven to fail hopelessly and badly. Pangocairo took over 18
