Any objections to swapping base compilers to make gcc4.7 the default?
John Marino
dragonflybsd at marino.st
Fri Feb 1 08:03:07 PST 2013
So
1) They are broken permanently until A) somebody patches them or B)
somebody updates the package which has a good chance of working with gcc47
2) They aren't broken if you use DRAGONFLY_CCVER=gcc44 which we have
done in the pkg themselves for those pkgs hopelessly broken on gcc4.7.
The ones that can be patches do not feature this. That shouldn't stop
people from using DRAGONFLY_CCVER on packages known to previously build.
It's a legitimate technique.
3) this is the latest excerpt bulk build (follows)
The gnustep-base is a separate multiplatform-disaster. The rest of the
failures are leaf packages. Nothing too major. Building with gcc44
probably gets you another 100 packages I would think, at most.
pkgsrc bulk build report
========================
DragonFly 3.3/i386
Compiler: gcc
Build start: 2013-01-26 00:26
Build end: 2013-01-30 20:15
Total number of packages: 12037
Successfully built: 11152
Failed to build: 149
Depending on failed package: 72
Explicitly broken or masked: 598
Depending on masked package: 66
Packages breaking the most other packages
Package Breaks Maintainer
-------------------------------------------------------------------------
devel/gnustep-base 22 rh at NetBSD.org
graphics/opencv 6 anthony.mallet at laas.fr
parallel/mpi-ch 5 asau at inbox.ru
textproc/cabocha 5 obache at NetBSD.org
emulators/qemu 4 pkgsrc-users at NetBSD.org
graphics/kdegraphics3 3 pkgsrc-users at NetBSD.org
devel/ruby-thrift 3 tonnerre at NetBSD.org
devel/xulrunner10 3 tnn at NetBSD.org
emulators/wine-devel 3 adam at NetBSD.org
games/plib 3 rh at NetBSD.org
On 2/1/2013 16:40, Justin Sherrill wrote:
> 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.
More information about the Users
mailing list