Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 394493 - ffmpeg-0.8.* ebuilds disable optimizations
Summary: ffmpeg-0.8.* ebuilds disable optimizations
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Media-video project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 392451
  Show dependency tree
 
Reported: 2011-12-12 23:14 UTC by Steve Dibb (RETIRED)
Modified: 2011-12-21 12:37 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Dibb (RETIRED) gentoo-dev 2011-12-12 23:14:02 UTC
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. :)
Comment 1 Luke-Jr 2011-12-12 23:15:50 UTC
Per my bug 392451, --disable-optimizations breaks ffmpeg on ARM completely.
Comment 2 Steve Dibb (RETIRED) gentoo-dev 2011-12-12 23:20:59 UTC
(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.
Comment 3 Alexis Ballier gentoo-dev 2011-12-14 12:18:00 UTC
(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.
Comment 4 Alexis Ballier gentoo-dev 2011-12-14 12:18:57 UTC
(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 :)
Comment 5 Luke-Jr 2011-12-14 15:44:00 UTC
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)... ;)
Comment 6 Alexis Ballier gentoo-dev 2011-12-14 15:55:54 UTC
(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
Comment 7 Luke-Jr 2011-12-14 16:15:23 UTC
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).
Comment 8 Alexis Ballier gentoo-dev 2011-12-14 17:23:41 UTC
(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.
Comment 9 Luke-Jr 2011-12-14 17:34:40 UTC
(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...
Comment 10 Alexis Ballier gentoo-dev 2011-12-14 17:46:16 UTC
(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
Comment 11 Luke-Jr 2011-12-14 18:14:13 UTC
(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...
Comment 12 Steve Dibb (RETIRED) gentoo-dev 2011-12-15 16:54:44 UTC
(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.
Comment 13 Alexis Ballier gentoo-dev 2011-12-15 19:44:52 UTC
(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.
Comment 14 Luke-Jr 2011-12-15 20:28:10 UTC
(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...
Comment 15 Alexis Ballier gentoo-dev 2011-12-21 12:37:15 UTC
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