media-libs/x265: Fix build on x32 by disabling assem… #173
Conversation
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
39fe282
to
8b8f2dc
Compare
bjacquin
changed the title
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
8b8f2dc
to
1aae5e0
Compare
|
Commit message is too long. Put very short explanation on summary line, then explain the whole thing in detail in body, i.e.: |
|
@gentoo/video |
mgorny
added
bugfix
assigned
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
1aae5e0
to
daee057
Compare
|
Pull requested updated as requested, upstream report made in videolan/x265#1 |
|
Errr, sorry for being picky, but I think pasting the build log in commit message is not a good idea ;-). Word the minimal description someone may need to understand the change. In particular, the description you gave on upstream commit is better than the one here ;-). |
|
Upstream videolan/x265#1 is not the official repo, report was made on https://bitbucket.org/multicoreware/x265/pull-requests/21/build-disable-march-selection-from/diff |
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
daee057
to
2c03843
Compare
|
Can you tell me if this is better now ? |
|
Yes, looks good. Just to be clear, what happens when you enable assembly on x32? Does it fail? I suggest you file a bug upstream about that too, they may want to update their asm, or implicitly disable it when unsupported ABI is used. |
|
Build fails, as reported upstream: https://bitbucket.org/multicoreware/x265/issues/198/assembly-code-fails-on-x32 |
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
2c03843
to
b8b5f1d
Compare
|
PR updaded for x265 1.8 |
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
b8b5f1d
to
182f180
Compare
|
lgtm, thanks! just one nitpick: it'd be good to have the bug number in a comment close to where you disable asm, as in my original suggestion: Unless asm optimizations are never intended to work on x32, I imagine a few years from now, people will wonder why this is disabled without warning :) |
| @@ -54,6 +58,8 @@ multilib_src_configure() { | |||
| if [ "${ABI}" = x86 ] ; then | |||
| use 10bit && ewarn "Disabling 10bit support on x86 as it does not build (or requires to disable assembly optimizations)" | |||
| mycmakeargs+=( -DHIGH_BIT_DEPTH=OFF ) | |||
| elif [ "${ABI}" = x32 ] ; then | |||
There was a problem hiding this comment.
If I may add my own nitpick, please use bash [[ ... ]]. Then quoting becomes unnecessary:
elif [[ ${ABI} = x32 ]] ; then
If that wouldn't be a problem, please also change the other conditional.
There was a problem hiding this comment.
PR updated as per your comment
x32 arch as defined on https://sites.google.com/site/x32abi is neither X86 nor X64, then forcing -march=i686 leads to build failure as wrong -march is used. Forcing -march, -mfloat-abi and -mfpu for ARM is also wrong As a global sanity sake, disable all forced -march in CMakeLists Upstream report: https://bitbucket.org/multicoreware/x265/pull-requests/21/build-disable-march-selection-from/diff Package-Manager: portage-2.2.20.1
bjacquin
force-pushed
the
dev/beber/x32-x265
branch
from
182f180
to
5658f1d
Compare
|
PR updated as per your comment |
|
if you wish to update per above nitpicks, feel free, otherwise it's good to go and I now see why you were using MULTILIB_ABI_FLAG: it is used in src_test... |
|
@bjacquin, your PGP key still seems to be missing on sks keyservers ;-). Please upload it. ( |
|
Hi Michał, I'm using a EdDSA GnuPG key and therefore keys.gnupg.net does not Cheers, On 14/10/2015 22:10, Michał Górny wrote:
Bertrand |
…bly code, patch to disable automagic march setup, bug #510890
Package-Manager: portage-2.2.20.1