The only thing I can think of: can you quantify which packages aren't building? It sounds like this will break some packages, at least temporarily, but I don't know which.
The ideal scenario is to never have anyone need to/care to put DRAGONFLY_CCVER into their mk.conf. That might be likely if the packages affected are old enough/rarely used enough. On Fri, Feb 1, 2013 at 4:03 AM, John Marino <[email protected]> wrote: > The gcc-4.4 compiler is still the default compiler on DragonFly-3.3. There > seems to be general consensus on IRC that it's time to promote gcc-4.7 to > that role and have gcc-4.4 serve as the backup. > > Is there any major objection to doing this? > > From a pkgsrc point of view, over 11,150 packages build with gcc-4.7. > There are some older packages that fail the stricter gcc-4.7 checks that > are easily patched, but they take time to add. However, one could take a > page from dports where gcc-4.4 is the primary compiler for pkgsrc > regardless of which the system uses. So to summarize: gcc-4.7 can already > build most of what gcc-4.4 can in pkgsrc (plus some that it can't), and > users could put "DRAGONFLY_CCVER?=gcc44" in the /usr/pkg/etc/mk.conf file > if they want to keep using gcc-4.4 for packages. > > There's only one known problem with gcc-4.7 right now: The plugin > mechanism introduced around gcc-4.6 doesn't work right. The world/kernel > doesn't use this mechanism and only 1-2 packages are failing because of it. > Nevertheless I'd like to fix it, so I'll attempt to do before before a > compiler switch. However, failing to do so shouldn't block the switch. > > So as the title says, is there a good reason to hold off on making gcc-4.7 > the primary compiler? > > John >
