| Summary: | media-libs/libtheora-1.0_beta2 compilation fails w/o -fomit-frame-point and w/ -fomit-frame-pointer -fforce-addr and w/ -O0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Graham Murray <graham> |
| Component: | [OLD] Library | Assignee: | Gentoo Media-video project <media-video> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | billl, gengor, jakub, pageexec, phajdan.jr, pva, srrijkers, vmatare+gbug, vxjasonxv |
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
updated pic-fix for theora 1.0-beta2
scanelf-textrel with beta3 |
||
|
Description
Graham Murray
2007-11-27 20:32:17 UTC
Try without -ggdb in your CFLAGS, but if that doesn't help you can as workaround enable USE="pic" to disable asm. I see, try also adding -fomit-frame-pointer in CFLAGS. *** Bug 200552 has been marked as a duplicate of this bug. *** + 27 Nov 2007; Samuli Suominen <drac@gentoo.org> + files/libtheora-1.0_beta2-flags.patch: + Restore -fomit-frame-pointer wrt #200549. in cvs.. Well, this still fails exactly the same even w/ -fomit-frame-pointer if -fforce-addr is used in CFLAGS. Also, did someone report this upstream? (In reply to comment #5) > Well, this still fails exactly the same even w/ -fomit-frame-pointer if > -fforce-addr is used in CFLAGS. Also, did someone report this upstream? > Manually removing -fforce-addr was the only way to get libtheora-1.0_beta2-r1 to build here for me. *** Bug 202505 has been marked as a duplicate of this bug. *** Reopening, fails w/ CFLAGS="-march=pentium3 -O0 -pipe" as well (Bug 202505) and there really should be something done upstream about this. Created attachment 138713 [details, diff]
updated pic-fix for theora 1.0-beta2
i've updated the current pic-fix patch so that the compiler doesn't run out of registers even when the frame pointer is used. note that this is replacement of the current in-portage patch, if you need a separate one then just interdiff them.
thanks, but it still fails with -fforce-addr here :/ though it gains one register, so we dont need -fomit-framepointer to be forced anymore. /bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c -o libtheora_la-dct_decode_mmx.lo `test -f 'enc/x86_32/dct_decode_mmx.c' || echo './'`enc/x86_32/dct_decode_mmx.c i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c enc/x86_32/dct_decode_mmx.c -fPIC -DPIC -o .libs/libtheora_la-dct_decode_mmx.o enc/x86_32/dct_decode_mmx.c: In function `FilterHoriz__mmx': enc/x86_32/dct_decode_mmx.c:93: error: can't find a register in class `GENERAL_REGS' while reloading `asm' enc/x86_32/dct_decode_mmx.c:95: error: can't find a register in class `GENERAL_REGS' while reloading `asm' make[2]: *** [libtheora_la-dct_decode_mmx.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -I../lib/dec -I../lib/enc -Wall -Wno-parentheses -fomit-frame-pointer -march=athlon-xp -O2 -pipe -fforce-addr -c dec/state.c -o libtheora_la-state.o >/dev/null 2>&1 make[2]: Leaving directory `/var/tmp/portage/media-libs/libtheora-1.0_beta2-r1/work/libtheora-1.0beta2/lib' make[1]: *** [all-recursive] Error 1 It seems the "m" constraints become "r" with -fforce-addr (if I understand it correctly), so the good old x86 is still starving registers there... (In reply to comment #10) > thanks, but it still fails with -fforce-addr here :/ > though it gains one register, so we dont need -fomit-framepointer to be forced > anymore. and that's what i intended to fix, sorry if i wasn't clear. see below. > It seems the "m" constraints become "r" with -fforce-addr (if I understand it > correctly), so the good old x86 is still starving registers there... according to http://gcc.gnu.org/gcc-4.3/changes.html : Command-line changes * -fforce-addr has been removed. It is now ignored by the compiler. so IMHO there's little to point to attempt to fix these issues when they're going to automatically go away next year anyway (not to mention that in cases like this it may very well be impossible, at least without extensive rewriting of the inline asm). (In reply to comment #11) > according to http://gcc.gnu.org/gcc-4.3/changes.html : > > Command-line changes > * -fforce-addr has been removed. It is now ignored by the compiler. eh, crap, that was for m68k, the general change involves only -fforce-mem. still, is there any point in supporting -fforce-addr here? (In reply to comment #12) > still, is there any point in supporting -fforce-addr here? Shrug, lets just filter it on x86 and be done with it; was mainly after fixing the -fomit-frame-pointer thing as forcing this makes debugging pretty much impossible on x86. (In reply to comment #13) > (In reply to comment #12) > > still, is there any point in supporting -fforce-addr here? > > Shrug, lets just filter it on x86 and be done with it; was mainly after fixing > the -fomit-frame-pointer thing as forcing this makes debugging pretty much > impossible on x86. not impossible but one will surely have to delve into asm for that. if there're other packages filtering no-frame-pointer i can take a look, just open a bug and CC me. -O0 shouldn't be allowed for other reasons... (In reply to comment #15) > -O0 shouldn't be allowed for other reasons... Luca, PLEASE do educate me on this. "Back in the day" and for the longest time, I used -O2. Since I've started participating in debugging a F/OSS project, their developers always complained about my backtraces looking "really ugly" and they attributed it to my -O2. Earlier this year, I gave SourceMage a try. When I gave up and came back to Gentoo, I started using -O0 in my CFLAGS in order to "be a better debugger". I know that -O* is a shorthand method for specifying a range of other various gcc flags, but not the nitty gritty details. Soooo. Why should -O0 not be allowed, and what should I use? -O1? -O2? -Os? Thanks! So, - Apply attached patch - filter-flags -fforce-addr - replace-flags -O0 -O2 - Remove forcing -fomit-frame-pointer from current patch And be done with it? > - Apply attached patch done > - filter-flags -fforce-addr not done > - replace-flags -O0 -O2 not done > - Remove forcing -fomit-frame-pointer from current patch done I've succesfully built it with -O0 -fforce-addr with gcc 4.2.2 However, I had issue on hardened with gcc 3.4 iirc. I'd bet this is a gcc bug. We could filter some flags but this would not be a good idea imho as its more gcc's fault than the package's. Moreover, gcc 4.3 changes.html seems wrong as -fforce-addr seems to have been removed not only for m68k, according to: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33713 and: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01651.html The funny thing is that it's gone for that exact reason... And thanks a lot for the updated patch ;) *** Bug 212194 has been marked as a duplicate of this bug. *** Both -fforce-addr and -frename-registers should be filtered: enc/x86_32/dct_decode_mmx.c:93: erreur: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ enc/x86_32/dct_decode_mmx.c:95: erreur: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ Samuli, Alexis, what the problem to filter flags based on gcc version? We have old compilers in the tree and will have for some time (year, may be even more?). Not filtering -fforce-addr breaks our hardened users as hardened still means gcc-3.4 in Gentoo or is that possible to use newer gcc somehow? If that's impossible (and it is AFAIK), please, add something like this into ebuild:
inherit toolchain-funcs flag-o-matic
if [[ $(gcc-version) == 3.4 ]] ; then
filter-flags -fforce-addr -frename-registers
fi
After irc discussion with aballier, the code suggested in #21 is added to ebuild and this bug is FIXED in the tree. *** Bug 215938 has been marked as a duplicate of this bug. *** (In reply to comment #22) > After irc discussion with aballier, the code suggested in #21 is added to > ebuild and this bug is FIXED in the tree. > Your workaround seems to fail wrt bug 215938. Ok, obviously I misread bug and nobody told me :/ Now filtering out -fforce-addr and -frename-registers on x86. libtheora-1.0_beta3 is now in portage, but it still has the line: use x86 && filter-flags -fforce-addr -frename-registers #200549 can you guys try removing that line from _beta3.ebuild and testing again? leaving it there untested is not a option :) Created attachment 150102 [details]
scanelf-textrel with beta3
beta3 builds correctly with both -fforce-addr and -frename-registers but it has text relocations.
And relocation exists in either case, with or without filter-flags. So at the moment it's safe to drop that line, but seems that new bug should be filled. (In reply to comment #28) > And relocation exists in either case, with or without filter-flags. So at the > moment it's safe to drop that line, but seems that new bug should be filled. > Someone needs to do that then. I don't have access to x86 hardware running Gentoo. 18 Apr 2008; Samuli Suominen <drac@gentoo.org> libtheora-1.0_beta3.ebuild: TEXTRELs are back and filter-flags isn't needed anymore according to bug #200549, comment #28. Updated PIC patch is needed. |
