fPIC and fstack-protector have been inhibited in the xine-lib ebuild via filter-flags. We should remove such filtering where reasonable, as it undermines the hardened project's efforts. The reason why PIC doesn't work in the portage build 1-rc6, is that the code does "#ifdef PIC" etc instead of "#ifdef __PIC__". I'll attach a patch that fixes this; for me, with this patch and fPIC/fstack-protector filter-flags removed, xine-lib builds fine and runs fine so far (I've played a DVD, mp3, wav and ogg through it without problems). ref. previously resolved/{invalid|fixed|wont} bugs #34736, #36759, #36789, #49482, #54788, #58413 Reproducible: Always Steps to Reproduce: 1.Remove the filter-flags -fPIC fstackprotector from the 1-r6 ebuild 2.emerge 3. Actual Results: Build dies due to non-PIC-compatible code. Expected Results: Software should have worked perfectly :) I've left this as "normal", although the current ebuild doesn't fail, as IMO it should be fixed (can't see a good reason not to). The current workaround of filtering fPIC/fstack-protector quietly does the opposite of what the user requested. I can't find anything in bugzilla indicating why fstack-protector was filtered; perhaps without the PIC fix it fails or perhaps there was a problem with earlier ssp implementations, I don't know. Whatever the reason, with the current stable hardened gcc (3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) it works fine for me so far.
Created attachment 42024 [details, diff] change "#ifdef PIC" to "#ifdef __PIC__"
Created attachment 42025 [details, diff] remove "filter-flags -fstack-protector -fPIC" from ebuild
Solar, Can you take a look at the patch and let me know if it works with hardened? If it does, I'll be more than willing to apply it to xine-lib.
I don't need to test it to tell you it's doing the right thing. At most what could change would be -#ifndef PIC -#ifndef __PIC__ +#if (!defined(PIC) || !defined(__PIC__))
Not sure about removing -fstack (don't see anything here that makes it safe todo so) I don't have the ChangeLog handy but I'd assume it was added for a reason at some point.
tseng added it last year, as he also wrote the pax quickstart he might remember why ?
Compiled with -fstack-protector and pic/pie and tested. Works well on x86 now. It should be save for everybody to use those two patches. (I remember the mess on xine-lib in earlier days. Now it seems really smooth.)
>>> media-libs/xine-lib-1_rc6 merged. This is with -fstack-protector and -fPIC both enabled with your patches and a new mmx patch I had to add (PIC + mmx = no no). -fforce-addr still has to be filtered, the emerge didn't like it. Thanks much for the patch too :).
Out of interest, why does "PIC + mmx = no no"? There's nothing intrinsic about mmx that breaks PIC that I can think of; they're independent technologies.
Kevin, the MMX support code uses asm, which makes use of the EBX register. On x86, this register is used for PIC code, so they conflict. You will most often see this manifest at build time with a compiler error begining with "breg:". HTH
Yes, I understand what the problems can be with PIC and hand-written asm. My point was that use of mmx per se does not interfere with PIC. If the only reason for saying "PIC + mmx = no no" is that some asm that is used when mmx is requested is not written to support PIC, then the real reason is that "PIC + non-pic asm = no no". I wanted to avoid spreading any idea that there's a fundamental problem with MMX that breaks the ABI w.r.t. PIC, in the general case. I'll look at the asm here again, as I thought it was all OK - I've submitted some stuff to fix the asm in ffmpeg (see #67947), but I didn't find any in xine-lib that were a problem (once the existing ifdefs used __PIC__).
