| Summary: | xine-lib-1.1.0 fails on hardened x86 due to (yet more) non-PIC code | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kevin F. Quinn (RETIRED) <kevquinn> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | hardened, ikelos |
| Priority: | High | ||
| Version: | 2005.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch fixing PIC/__PIC__ stuff, in addition to already present 02_all_pic.patch | ||
Seems like we're missing PIC/__PIC__ problems on new ffmpeg snapshot in xine-lib. Can you please tell me where it fails? Enabling/disabling pic/fpic for hardened or not will break badly on arches where shared libraries *needs* to be built with -fPIC. Also, --with-external-ffmpeg is disabled for now as the version of ffmpeg currently in portage is too old for xine-lib (need a newer snapshot). Created attachment 64518 [details, diff]
patch fixing PIC/__PIC__ stuff, in addition to already present 02_all_pic.patch
This is the patch I applied before trying different configure options. However
compilation fails due to more register allocation errors - i.e. code that
doesn't work just by changing 'PIC' to '__PIC__'. To fix these means hacking
more deeply in the assembler code, which is a pita to maintain.
Perhaps I wasn't clear about the configure options. The default state on x86
is '--disable-fpic', on other arches the presumably default state is
'--enable-fpic'. I was suggesting '--enable-fpic' for x86, to undo the
default. This causes the build to use libtool properly to generate code for
shared libraries, which adds '-DPIC -fPIC' in the right places (which also
means 02_all_pic.patch becomes unnecessary). If you're worried about it, you
could always add '--enable-fpic' only if use hardened && use x86.
Similarly with '--with-pic' - if you're worried about breaking other arches
make it conditional on 'use x86' as well, and wait to see if other hardened
arches fail (hardened ppc might, for example).
The patch you attached is not complete. Sorry I was able to take a look at that just today. I've updated 02_all_pic.patch to fix all the PIC / __PIC__ errors, and now should be ok. --enable-fpic and --with-pic just make it use -fPIC -DPIC everywhere, so the problem had to be with missing PIC/__PIC__ patching. Feel free to reopen if it's still an issue. |
I initially thought to extend the 02_all_pic.patch; but then saw: --disable-fpic disable -fPIC on shared libs (default on x86) --with-pic try to use only PIC/non-PIC objects [default=use both] in configure. Switching these on and removing 02_all_pic.patch makes for a successful build on hardened systems. It switches off all the non-PIC code (which means most of the "accelerated" code), but hardened users implicitly sacrifice perfomance for security anyway. I suggest adding: $(use_enable hardened fpic) \ $(use_with hardened pic) \ to the econf invocation; I've tries this and it works for me. Probably easier to maintain in the long run than code patches for non-PIC assembler. I also tried --with-external-ffmpeg which would have been nice, but that failed to build (haven't investigated further). There are still textrels, but that's for another day.