| Summary: | media-libs/libvpx: -O3 flag is not stripped | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | . <dev.rindeal+gentoo> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chromium, steve.dibb |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=547194 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | disable optimizations | ||
|
Description
.
2016-09-21 15:44:52 UTC
build/make/configure.sh is adding them, enabling optimizations is set by default. The ebuild could be updated to run the --disable-optimizations and just let us use our own, or we could add an optimization USE flag, and then let them set it. Either way, they add a lot of stuff to cflags on their own, so could be a slippery slope. Created attachment 486018 [details, diff]
disable optimizations
(In reply to Steve Dibb from comment #2) > Created attachment 486018 [details, diff] [details, diff] > disable optimizations This patch seems reasonable to me. what do they add as cflags ? it'll probably work on x86* but e.g. altivec or neon asm usually fails at the 'as call' stage if not used with proper flags iirc (In reply to Alexis Ballier from comment #4) > what do they add as cflags ? Turns on at least -O2: if enabled optimizations; then if enabled rvct; then enabled small && check_add_cflags -Ospace || check_add_cflags -Otime else enabled small && check_add_cflags -O2 || check_add_cflags -O3 fi fi rvct is for armv6, armv7 "enabled small" is another configure flag that can be passed, --enable-small, and this is the only place it's used. > it'll probably work on x86* but e.g. altivec or neon asm usually fails at > the 'as call' stage if not used with proper flags iirc There's other stuff in here for neon asm as well, but I don't know what it does. One example: if enabled neon || enabled neon_asm; then check_add_cflags -mfpu=neon #-ftree-vectorize check_add_asflags -mfpu=neon fi Here's the last place it uses the optimizations configuration:
gcc*)
link_with_cc=gcc
tune_cflags="-march="
setup_gnu_toolchain
#for 32 bit x86 builds, -O3 did not turn on this flag
enabled optimizations && disabled gprof && check_add_cflags -fomit-frame-pointer
;;
gprof is "gprof profiling instrumentation", which is also not enabled by default.
So the question is, whose CFLAGS to accept? It's always a tricky issue with codecs, and I generally fall in favor with accepting upstream's recommendations. We could throw in an optimizations USE flag or custom-cflags and strip it all, but I see too much changing it to just cause problems down the road for someone at the expense of them thinking they're making things better.
My recommendation: strip -Os and add optimizations use flag.
(In reply to Steve Dibb from comment #5) > (In reply to Alexis Ballier from comment #4) > > what do they add as cflags ? > > Turns on at least -O2: > > if enabled optimizations; then > if enabled rvct; then > enabled small && check_add_cflags -Ospace || check_add_cflags -Otime > else > enabled small && check_add_cflags -O2 || check_add_cflags -O3 > fi > fi if that's the only place this has any effect then it definitely makes sense to disable optimizations (In reply to Steve Dibb from comment #6) > So the question is, whose CFLAGS to accept? It's always a tricky issue with > codecs, and I generally fall in favor with accepting upstream's > recommendations. We could throw in an optimizations USE flag or > custom-cflags and strip it all, but I see too much changing it to just cause > problems down the road for someone at the expense of them thinking they're > making things better. Nah, I think your patch is the way to go then: I see very little value of a CFLAGS from upstream only adding -O2 or -O3, taking into consideration that what those flags mean change a lot between gcc versions. (In reply to Alexis Ballier from comment #8) > (In reply to Steve Dibb from comment #6) > > So the question is, whose CFLAGS to accept? It's always a tricky issue with > > codecs, and I generally fall in favor with accepting upstream's > > recommendations. We could throw in an optimizations USE flag or > > custom-cflags and strip it all, but I see too much changing it to just cause > > problems down the road for someone at the expense of them thinking they're > > making things better. > > > Nah, I think your patch is the way to go then: I see very little value of a > CFLAGS from upstream only adding -O2 or -O3, taking into consideration that > what those flags mean change a lot between gcc versions. That works. Looked at 1.6.0 and 1.6.1 build systems, and there's no additional changes to the configure.sh script compared to 1.5.0. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b30ae68f410ae68694128bf6c34125a4b277b726 commit b30ae68f410ae68694128bf6c34125a4b277b726 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-07 02:06:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-07 02:07:28 +0000 media-libs/libvpx: fix build on ARM, don't inject -O3 Closes: https://bugs.gentoo.org/594634 Closes: https://bugs.gentoo.org/547194 Signed-off-by: Sam James <sam@gentoo.org> media-libs/libvpx/libvpx-1.10.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |
