needs flags to be filtered Reproducible: Always Steps to Reproduce: 1.-fPIC in make.conf 2.emerge mythtv 3. Actual Results: crashed with this error error: can't find a register in class `BREG' while reloading `asm' Expected Results: no error too lazy to fill out the emerge -info
This is the second flag that was requested to be filtered...we got quite a collection going. Added.
That doesnt make sense. "-fPIC" is a very specific flag only usefull in shared libraries. Contrary to urban legends prelinking does NOT NEED IT; or the ebuild is REALLY BROKEN. -fPIC in global CFLAGS simply does not make sense; it is counter productive; it considerably decreases performance. A better approach in my eyes is to educate users about proper CFLAGS. All this -fPIC filtering all over portage just serves one purpose; it make Gentoo look unprofesionell!
this was done after a discussion with solar ... one thing he pointed out was the perf hit is usually 'significant' on the x86 architecture, while on some architectures a few registers are reserved for PIC simply because it is required (amd64, alpha, hppa are some examples iirc)
Excuse me, Reporter. Before you accuse Gentoo of unprofessionalism, and start rattling off lies about the uselessness of -fPIC, please do your homework. -fPIC is a key component of our "Hardened Gentoo" project, and allows executables to be fully remapped in memory by ASLR. For more info, see pax.grsecurity.net. So, go educate *yourself* and come back a little less accusatory. Thanks, Reporter!
Thats shifting the subject. Read again: > Steps to Reproduce: > 1.-fPIC in make.conf > 2.emerge mythtv > 3. > > Actual Results: > crashed with this error > error: can't find a register in class `BREG' while reloading `asm' Neither Benjamin or me said anything about pax; thats just where the subject usually ends up everytime -fPIC is brought up. Its a very usefull flag if used in the right place; make.conf simply isint one of them. 1. im well aware of the inner workings of pax 2. the hardened profile adds -fPIC transperently 3. non-hardened users should not be affected by all this at all 4. bc of 2. filter-flags -fPIC does have no effect on hardened anyways The big inconsistency is; if some1 reports an ebuild fails to build with -fPIC sometimes their asked why they want -fPIC in CFLAGS at all (right thing to do), sometimes a filter-flags is added. Im still a big gentoo fan, but that DOES look unprefessionell in the eyes of some people. I agree in one thing: mythtv needs a patch to work under hardened; but: 1. -fPIC in global CFLAGS is completely unrelated 2. non-hardened users should be unaffected 3. please refrain from calling me a liar. thanks.
read the code for filter-flags -fPIC thanks.
Reporter I appreciate the insight on this bug, this was something that solar refrenced me to start using for security purposes. If a program does not compile with that flag, then it should be fixed, so I filed a bug and was contacted by spanky and from there he also gave me the same negativitiy you did but he didn't know it was going to be implemented in the future. I explained the problem on IRC and that's where the discussion went. Reporter if you see a bug submitted by a gentoo developer or a gentoo developer already working on it, please do some homework and try talking to us on irc if you have questions instead of saying we're totally lost. This will make you and the developers much happier people and we can actually fix it together=)
FACT: Gentoo's current entire supported infrastructure uses only PIC code on x86 and soon -pie on all servers for it's security benefits.
Go with me on this; I'm trying to make a point here. One of the reasons I chose to respond to a report by a dev rather than a regular user. My points might be challenging sometimes; but most of the time thats the only way to get your attention. Consider this scenario: Your trying to promote gentoo usage in a production environment. Your boss, a person with with UN*X in their baby formular, sees all this "filter-flags -bar" all over portage. Their first impression is, "Why dont they just say, "retry with sane CFLAGS before filing a bug report like bugzille tells you to?"". Fact is, in regular, non-hardened environments, -fPIC in global CFLAGS really does be counter productive. (this also applies to lotsa other flags currently filtered) Only thing they see is user reporting problem with this flag ===> maintainer filtering this flag no matter how little sense it makes in regular environments; 50 percent of the time :( append-flags -<hardened-specific-flag>, but only applied in hardened environments does exactly the same thing but is alot more clear. To the outside, filter-flags -fPIC in all profiles looks like the person adding it does not know what it does; different dev in different bug saying to remove it from CFLAGS does the rest. And no, most bosses dont hang out on IRC. They dont even want to evaluate hardened specific patches in non hardened profiles.
