from the linux make.defaults # make sure toolchain has sane defaults <tooclhain@gentoo.org> USE="${USE} mudflap fortran openmp" This should be moved to USE defaults as many other packages use openmp and fortran USE. It has to be discussed if these days openmp should be global anyways.
your logic doesnt make much sense. the location of use defaults has nothing to do with how other packages `use` or DEPEND on things. package dependencies on these USE flags being enabled always has to be there. moving the defaults from the linux profile to the package needs coordination with all the other profile maintainers so they can then set their profile to default with these things off.
Probably I wrote it missleading. Adding the USE to the make.defaults will enable it for all packages, but you want to have it enabled only for gcc. So adding it to the ebuild as enabled by default (IUSE="+openmp +fortran" is what I mean) makes more sense as it doesn't influence other packages. Not every package having a fortran USE needs to have in enabled to be in a sane state.
have you done some basic builds with this change to make sure most things continue to work ? that way anything that breaks, we can just treat as one-off bugs rather than many people hitting failures ...
I think these have to be treated on an individual basis. I'm not necessarily opposing moving 'mudflap' or even 'fortran' out of USE in make.defaults and into sys-devel/gcc's IUSE or a package.use entry. otoh, 'openmp' is utilized (sometimes with quite dramatic performance increase) by other packages like imagemagick. So if removing it from here would otherwise result in the "global turn-off" of 'openmp' - I would not welcome that change. That's not to say 'openmp' couldn't be moved to the arch/os (or elsewhere) areas of the profiles where other (global-ish) USE flags are defined.
(In reply to comment #2) > Probably I wrote it missleading. Adding the USE to the make.defaults will > enable it for all packages, but you want to have it enabled only for gcc. So > adding it to the ebuild as enabled by default (IUSE="+openmp +fortran" is what > I mean) makes more sense as it doesn't influence other packages. Not every > package having a fortran USE needs to have in enabled to be in a sane state. We'd have to move every gcc ebuild and toolchain.eclass to EAPI 1. That's probably minor but there's talk now and then about removing that EAPI, and porting to 2 isn't a walk in the park. I'd like to stay at 0 if we can.
(In reply to comment #3) > have you done some basic builds with this change to make sure most things > continue to work ? that way anything that breaks, we can just treat as one-off > bugs rather than many people hitting failures ... spoken for fortran, this isn't needed globally. Actually most people disable it directly from what I heard. But I would think that beside the performance penalty, also openmp can be remove although this would be not clever. The mudflap I don't know. (In reply to comment #5) > We'd have to move every gcc ebuild and toolchain.eclass to EAPI 1. That's > probably minor but there's talk now and then about removing that EAPI, and > porting to 2 isn't a walk in the park. I'd like to stay at 0 if we can. That's an argument, although it should be checked how much really has to be done. Once at EAPI=2 it is an easy move to 4. The comment to the entrance says "make sure toolchain has sane defaults" which is with current EAPI not the correct way to do in make.defaults.
(In reply to comment #6) > > We'd have to move every gcc ebuild and toolchain.eclass to EAPI 1. That's > > probably minor but there's talk now and then about removing that EAPI, and > > porting to 2 isn't a walk in the park. I'd like to stay at 0 if we can. > > That's an argument, although it should be checked how much really has to be > done. Once at EAPI=2 it is an easy move to 4. That's not a goal we want to aim for. I'm of the mind that base system packages should be kept at the absolute minimum EAPI possible. I don't know how hard it would be to move to EAPI 2, just that I'd rather not be forced to find out. :)
true, i hadnt thought of EAPI issues
Seems upstream fixed this alreadyi 1.0.1: http://pcmanfm.git.sourceforge.net/git/gitweb.cgi?p=pcmanfm/libfm;a=commit;h=8972eaaef0bb43491b7578dd3e8c9f14455d1d6a Hwoarang is the package bumpable? An off by 4 stack overflow may be enough to be exploitable if properly done.
Seems I really mistook the browser tab when answering the bug, sorry for that and the added noise. I'm reverting it back.
for bsd, I don't really mind and would really prefer gcc to have use defaults so that we can easily follow toolchain maintainers / upstream defaults.
Actually I'm not sure there's much really calling for USE defaults on gcc... cxx, nls, openmp, multilib, and nptl are used by used by other ebuilds and should continue to be set in the profiles. mudflap shouldn't be enabled by default IMO. fortran is debatable but I don't think it should be enabled either (see my mail to -dev). nossp and nopie could be changed to ssp and pie, but people are saying they'd rather just see them disappear altogether. I'd like to hear hardened's opinion on that first though. Everything else should default to disabled.
(In reply to Ryan Hill from comment #12) > Actually I'm not sure there's much really calling for USE defaults on gcc... > > cxx, nls, openmp, multilib, and nptl are used by used by other ebuilds and > should continue to be set in the profiles. Is't cxx needed by default to even build gcc on newer versions? > > mudflap shouldn't be enabled by default IMO. > > fortran is debatable but I don't think it should be enabled either (see my > mail to -dev). > > nossp and nopie could be changed to ssp and pie, but people are saying > they'd rather just see them disappear altogether. I'd like to hear > hardened's opinion on that first though. Remove them do we say, but the nopie flag is for disable the pie patching to. > > Everything else should default to disabled.
(In reply to Magnus Granberg from comment #13) > Is't cxx needed by default to even build gcc on newer versions? Yes the cxx flag doesn't do anything for >=4.8, but external stuff depends on it and we can't remove it without breaking things right now.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1.619&r2=1.620 I'll leave this open until the ebuilds are migrated and the defaults are removed from the profiles.
(In reply to Ryan Hill from comment #14) > (In reply to Magnus Granberg from comment #13) > > > Is't cxx needed by default to even build gcc on newer versions? > > Yes the cxx flag doesn't do anything for >=4.8, but external stuff depends > on it and we can't remove it without breaking things right now. I'm pretty sure gcc[cxx(+)] is not a terribly major change.
I'm talking cross-compiling/stage building, not ebuilds.
prefix has no real voice in this
I believe this is done.
