media-video/ffmpeg-0.8.* ebuilds have --disable-optimizations, which is a change from 0.7 branch where it was only enabled if custom-cflags was set. I'd like to switch 0.8 branch back to the 0.7 branch's behavior, but I'd like to get feedback first. aballier, it looks like you first changed it in 9999, so I'm curious why it was disabled in the first place. :)
Per my bug 392451, --disable-optimizations breaks ffmpeg on ARM completely.
(In reply to comment #0) > aballier, it looks like you first changed it in 9999, so I'm curious why it was > disabled in the first place. :) Let me clarify -- I don't care about 9999 doing it's own thing, but I'm guessing that when you bumped 0.8, you used 9999 as the template.
(In reply to comment #2) > (In reply to comment #0) > > > aballier, it looks like you first changed it in 9999, so I'm curious why it was > > disabled in the first place. :) > > Let me clarify -- I don't care about 9999 doing it's own thing, but I'm > guessing that when you bumped 0.8, you used 9999 as the template. $ ./configure --help | grep disable-optimizations --disable-optimizations disable compiler optimizations so that it doesnt append extra stuff to make.conf's CFLAGS. compiler optimizations are not for us.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > > > aballier, it looks like you first changed it in 9999, so I'm curious why it was > > > disabled in the first place. :) > > > > Let me clarify -- I don't care about 9999 doing it's own thing, but I'm > > guessing that when you bumped 0.8, you used 9999 as the template. > > $ ./configure --help | grep disable-optimizations > --disable-optimizations disable compiler optimizations > > so that it doesnt append extra stuff to make.conf's CFLAGS. compiler > optimizations are not for us. btw, needless to say that for me 'custom-cflags' is a nonsensical workaround for broken packages :)
That might make a little sense if it didn't break ffmpeg, and if the user's CFLAGS were used (they're ignored right now)... ;)
(In reply to comment #5) > That might make a little sense if it didn't break ffmpeg, and if the user's > CFLAGS were used (they're ignored right now)... ;) please check your claims and explain, i get _my_ cflags (among others) in config.mak here
I can confirm that my CFLAGS did make it into config.mak:CFLAGS. They did NOT make it into config.mak:CPPFLAGS, though that might not matter for ffmpeg. However, I was talking mainly about during configure: NEON support is not detected because -mfpu=neon is not passed via --extra-cflags (it IS, however, in my CFLAGS).
(In reply to comment #7) > I can confirm that my CFLAGS did make it into config.mak:CFLAGS. They did NOT > make it into config.mak:CPPFLAGS, though that might not matter for ffmpeg. hopefully your CFLAGS did not make it through CPPFLAGS :) > However, I was talking mainly about during configure: NEON support is not > detected because -mfpu=neon is not passed via --extra-cflags (it IS, however, > in my CFLAGS). What matters here is ASFLAGS. Please try to set -mfpu stuff there too.
(In reply to comment #8) > What matters here is ASFLAGS. Please try to set -mfpu stuff there too. ASFLAGS is not documented on any Gentoo site...
(In reply to comment #9) > (In reply to comment #8) > > What matters here is ASFLAGS. Please try to set -mfpu stuff there too. > > ASFLAGS is not documented on any Gentoo site... so? i am trying to help _you_ on _your_ issue there... anyway, ASFLAGS stuff is arm specific (gas refuses to compile asm if target cpu doesnt support it, when on x86/amd64 it doesnt check for that) @beandog: once the arm stuff is resolved, i see no reason to go back to the custom-cflags stuff: "cflags shall be respected, period", no? -> closing this bug, as arm stuff belongs to bug #392451
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > What matters here is ASFLAGS. Please try to set -mfpu stuff there too. > > > > ASFLAGS is not documented on any Gentoo site... > > so? i am trying to help _you_ on _your_ issue there... Erm, this is a _Gentoo_ issue. Documentation, at the very least. > anyway, ASFLAGS stuff is arm specific (gas refuses to compile asm if target cpu > doesnt support it, when on x86/amd64 it doesnt check for that) If my current compile confirms ASFLAGS fixes it, then perhaps it would best be assigned to the ARM team (for ASFLAGS documentation)... > "cflags shall be respected, period", no? Actually, it makes sense (and seems standard) to override CFLAGS minimally for special cases where a specific feature is required...
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > > > aballier, it looks like you first changed it in 9999, so I'm curious why it was > > > disabled in the first place. :) > > > > Let me clarify -- I don't care about 9999 doing it's own thing, but I'm > > guessing that when you bumped 0.8, you used 9999 as the template. > > $ ./configure --help | grep disable-optimizations > --disable-optimizations disable compiler optimizations > > so that it doesnt append extra stuff to make.conf's CFLAGS. compiler > optimizations are not for us. Can you elaborate? Upstream is saying that we are breaking their builds without this. And since there is no consistency between branches, we need to decide on one. I'm voting for the 0.7 behavior.
(In reply to comment #12) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #0) > > > > > > > aballier, it looks like you first changed it in 9999, so I'm curious why it was > > > > disabled in the first place. :) > > > > > > Let me clarify -- I don't care about 9999 doing it's own thing, but I'm > > > guessing that when you bumped 0.8, you used 9999 as the template. > > > > $ ./configure --help | grep disable-optimizations > > --disable-optimizations disable compiler optimizations > > > > so that it doesnt append extra stuff to make.conf's CFLAGS. compiler > > optimizations are not for us. > > Can you elaborate? Upstream is saying that we are breaking their builds > without this. i dont want -O3 to be injected just because upstream thinks its better. > And since there is no consistency between branches, we need to decide on one. > I'm voting for the 0.7 behavior. have you checked today's 0.9 or 9999 ? optimizations are now enabled but 'optflags' come from make.conf, which should be the desired behavior. 0.7 behavior with custom-cflags is certainly broken. 0.8 was broken too because it also disabled some function inlining. 0.9 should be good.
(In reply to comment #13) > have you checked today's 0.9 or 9999 ? Will do as soon as I can... KDE was bumped from 4.6 to 4.7, and it take quite some time to build on 600 MHz ARM...
timeout, closing again assuming 0.9/9999 is good for you if you have something to add, please be quick, ffmpeg 0.9 shall go stable rather sooner than later