media-libs/x264 patch conflicts

[ElDavoo]

Hello, I've been trying to update x264 but it fails:

Source unpacked in /var/tmp/portage/media-libs/x264-0.0.20190903-r1/work Applying lto.patch ... [ ok ] lto-overlay: LTO patches applied. Preparing source in /var/tmp/portage/media-libs/x264-0.0.20190903-r1/work/x264-snapshot-20190903-2245 ... Applying x264-0.0.20190903-STRINGS.patch ... patching file configure Hunk # 1 succeeded at 532 (offset -9 lines). Hunk # 2 FAILED at 1018. 1 out of 2 hunks FAILED -- saving rejects to file configure.rej

This happens because x264-0.0.20190903-STRINGS.patch has a context line that gentooLTO's lto.patch changes. I'm not sure how this issue should be solved.

[telans]

I don't suppose the patch can be patched?

[emerzon]

I think it's more like a patch order issue. LTO patches are being applied before the official patch. Could potencially patch the patch to fix the context line, but feels very ugly.

[ElDavoo]

Take a look at this gentoo issue and its fix .

[InBetweenNames]

Yeah it's definitely a patch ordering issue. We might have to fork the ebuild.

[Althorion]

In the meantime—how does one apply this fix? I tried using it (i.e., I put it in /etc/portage/patches/media-libs/x264-0.0.20190903-r1/patching-order.patch) both with and without this repo’s patch and the compilation fails in both of those cases—with patching order error if with, and with endian test failed if without.

[mylanconnolly]

@Althorion for what it's worth, what I did was take the patch here and save it in a file I created /etc/portage/patches/media-libs/x264/endian-fix.patch and then was able to install media-libs/x264-0.0.20190903-r1 without any further issue.

I have no other patches in my /etc/portage/patches directory for x264 or anything else.

[Althorion]

@mylanconnolly when I do just that, I get the patching order error:

patching file configure
Hunk #1 succeeded at 532 (offset -9 lines).
Hunk #2 FAILED at 1018.
1 out of 2 hunks FAILED -- saving rejects to file configure.rej

If I would do that and remove /var/db/repos/lto-overlay/sys-config/ltoize/files/patches/media-libs/x264/lto.patch, I would get the endian test error instead.

[mylanconnolly]

Hm, I did not remove the lto.patch file. Does it work with that patch in place? If not, sorry, I am not sure why it works in my case then. My portage tree is 2 days old, not sure if that makes a difference.

Sent from ProtonMail mobile

-------- Original Message -------- On Jul 7, 2020, 6:47 PM, Althorion wrote:

@mylanconnolly when I do just that, I get the patching order error:

patching file configure Hunk #1 succeeded at 532 (offset -9 lines). Hunk #2 FAILED at 1018. 1 out of 2 hunks FAILED -- saving rejects to file configure.rej

If I would do that and remove /var/db/repos/lto-overlay/sys-config/ltoize/files/patches/media-libs/x264/lto.patch, I would get the endian test error instead.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Althorion]

No, unfortunately. If I have both patches or only the gentooLTO patch, it won't patch at all. If I would have only that extra patch, it would fail at checking the endianess. The only way for me to build it is to have none of the patches and disable LTO for that package.

[Cognomines]

Here is the lto.patch that will work with the latest media-libs/x264/x264-9999.ebuild keyworded as testing.

/var/lib/layman/lto-overlay/sys-config/ltoize/files/patches/media-libs/x264 # cat lto.patch 
--- a/configure 2020-07-07 20:37:00.103200843 -0400
+++ b/configure 2020-07-07 20:36:38.819867863 -0400
@@ -1017,7 +1017,7 @@
 CPU_ENDIAN="little-endian"
 if [ $compiler = GNU ]; then
     echo "int i[2] = {0x42494745,0}; double f[2] = {0x1.0656e6469616ep+102,0};" > conftest.c
-    $CC $CFLAGS conftest.c -c -o conftest.o 2>/dev/null || die "endian test failed"
+    $CC $CFLAGS conftest.c -c -o conftest.o -shared 2>/dev/null || die "endian test failed"
     if (${STRINGS} -a conftest.o | grep -q BIGE) && (${STRINGS} -a conftest.o | grep -q FPendian) ; then
         define WORDS_BIGENDIAN
         CPU_ENDIAN="big-endian"

The issue will come back if the configure file changes, but that is true for any patch with changing software. One lto patch file cannot work for all ebuilds. Ebuilds would probably have to be forked. I suppose the ebuild could be forked from the most recent snapshot rather than live.

[GrbavaCigla]

How do I disable lto for x264 or any other package?

[jiblime]

For personal flags, you can create a file in /etc/portage/package.cflags and use *FLAGS-=-flto*. You can also edit ltoworkarounds.conf, but will run into extra steps when syncing up the tree https://github.com/InBetweenNames/gentooLTO/issues/412

Example:

create /etc/portage/package.cflags/nolto.conf and put this in it:

media-libs/x264 *FLAGS-=-flto* # You can put comments here for clarity
sys-fs/multipath-tools *FLAGS-=-flto*

When emerging media-libs/x264, the build.log will show:

/etc/portage/package.cflags/nolto.conf -> media-libs/x264: *FLAGS-=-flto* # You can put comments here for clarity

Explanation:

*FLAGS is a wildcard for any variable that is inherited from make.conf, such as CFLAGS, CXXFLAGS, LDFLAGS, etc.

-= means to strip the named flags. += would mean to append the named flags

-flto* strips any flag beginning with -flto, such as -flto=4, -flto=thin, -flto-compression-level=5

---

How do we disable lto-overlay patches?

[GrbavaCigla]

Thanks!

[Titaniumtown]

Will there be a fix that will be added to this repo?

[InBetweenNames]

Yeah, I think requiring x264-9999 is reasonable -- it's better than not having this package at the very least.

[InBetweenNames]

@jiblime I agree, we should have a mechanism to override LTO patches from being applied from the overlay

[Titaniumtown]

glad my PR got merged :) thanks again @Cognomines!

[Titaniumtown]

Now we have to figure out a way to unmask x264-9999 when you install the ltoize package.