Summary: | media-video/mplayer needs at least -O level on x86_64 to gain -fomit-frame-pointer | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Limansky <limanski> |
Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | Reimar.Doeffinger |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Mike Limansky
2009-10-13 18:48:39 UTC
Created attachment 206995 [details]
Build log
Build log for the problem (gcc-4.3.3).
Compiling without -fomit-frame-pointer is in no way supported by upstream, if you need that unset HAVE_EBP_AVAILABLE manually and expect vastly slower code for some things. I'll check it. So, I suppose the ebuild shall be fixed to use proper CFLAGS, right? It seems like it not depends on fomit-frame-pointer option. Try mplayer-1.0_rc4_p20091026. Well, -fomit-frame-pointer does not really have any effect without at least -O or possibly -O2 I think. Anyway, the compilation options seem thoroughly broken (at lest very suboptimal) to me, personally I'd consider broken compilation preferable to the badly performing code this would probably give. Now the real question is of course how those compilation options ended up like this... (In reply to comment #0) > CFLAGS="-march=k8 -pipe -fomit-frame-pointer" > CXXFLAGS="-march=k8 -pipe -fomit-frame-pointer" Missing -O<ptimization> level.(In reply to comment #6) > Now the real question is of course how those compilation options ended up like > this... ^^ It seems to me that we need a code snip that will detect if no >= -O1 flag is specified, and then append -O1 as failsafe. If you ask for my opinion: I am very much opposed to fiddling with the compilation options behind the user's back. If you want to do that, then just always use the only variant supported by upstream: those that MPlayer's configure detected. Otherwise just e.g. replicated the warning from MPlayer's configure: if you insist on overriding compilation flags, better be prepared to fix the issues yourself (or if you want something more user-friendly). However in the case of missing -O2 or something I really think the warning belongs on some higher level, I strongly doubt there are many users who really intend that. I forgot: A patch to implement detection of HAVE_EBP_AVAILABLE similar to HAVE_EBX_AVAILABLE would be possible, too - except as said the question is if a slow system and slow MPlayer is better than it not compiling at all for most users or not. It's been long since I tested, but I think this e.g. has a more than 10% speed impact on H.264 with CABAC (probably the case where performance is needed most), without counting the possible performance losses due to missing -O2. That's why I actually removed all the remaining fiddling from the latest snapshot (with todays date). The users environment is now respected, with the exception that -fomit-frame-pointer is appended unless USE="debug" is used on x86. On x86_64 -fomit-frame-pointer is appended by gcc itself with -O set: "-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging", ref. `man gcc` The check you mentioned would be the best possible outcome of course, as I agree that a slow-mplayer is better than no-mplayer. + 27 Oct 2009; Samuli Suominen <ssuominen@gentoo.org> + mplayer-1.0_rc4_p20091026-r1.ebuild: + If no -O flag is specified, append-flags -O2 (to gain -fomit-frame-pointer + by gcc) wrt #288918 Failsafe added. Not the ideal solution, but same as we already have for FFmpeg. |