Summary: | media-libs/x264-0.0.20130912 - src_configure(): endian test failed with LTO | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Kredba <kredba> |
Component: | [OLD] Library | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | candrews, contyk, fabio.coatti, forza, gl, krissn, lynx1534, mylan, neddyseagoon, sam, skobkin-ru, StormByte, zhuyifei1999 |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=583076 https://code.videolan.org/videolan/x264/-/merge_requests/45 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: |
x264-lto.patch
x264-0.0.20151011-lto.patch x264-0.0.20170701-lto.patch Newer patch to fix LTO configure bug |
Description
David Kredba
2014-01-10 16:42:50 UTC
Please attach your config.log to this bug report. Here it is: checking whether __ILP32__ is true... no -------------------------------------------------- conftest.c:2:2: error: #error #error ^ -------------------------------------------------- Failed program was: -------------------------------------------------- #if !(__ILP32__) #error #endif -------------------------------------------------- x264 configure script Command line options: "--prefix=/usr" "--libdir=/usr/lib64" "--disable-cli" "--disable-avs" "--disable-lavf" "--disable-swscale" "--disable-ffms" "--disable-gpac" "--enable-pi checking whether x86_64-pc-linux-gnu-gcc works... yes checking whether x86_64-pc-linux-gnu-gcc supports for( int i = 0; i < 9; i++ ); with -std=gnu99... yes checking whether yasm supports vpmovzxwd ymm0, xmm0... yes checking whether x86_64-pc-linux-gnu-gcc supports __asm__("pabsw %xmm0, %xmm0");... yes checking for -mpreferred-stack-boundary=5... yes DIED: endian test failed This is most likely caused by the x32 patch in the ebuild. ...or the CFLAGS patch. After I deleted lib32/pkgconfig & co folders owned by not yet re-emerged packages (to -multilib) it rebuilt correctly. I am sorry, it did not rebuilt correctly. It fails the same way as before. I mixed it with before failing libjpegturbo (which I found is -flto problem). When the patch is removed the only difference is that config.log not begins with #if !(__ILP32__) #error #endif The rest is the same. When I ran this by hand it not writes anything to output and .o file is created. echo "int i[2] = {0x42494745,0}; double f[2] = {0x1.0656e6469616ep+102,0};" > conftest.c gcc -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin conftest.c -c -o conftest.o /root/conftest.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped 0000000000000001 C __gnu_lto_slim 0000000000000001 C __gnu_lto_v1 Without -flto: /root/conftest.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped 0000000000000000 D f 0000000000000010 D i And my final sorry, without -flto -fuse-linker-plugin it compiles fine. Next time I will try to do deeper research before opening a case here. Until authors will count with LTO this have to be built without LTO. Would you like to submit filtering cflags or have I to close this as invalid? Created attachment 380064 [details, diff]
x264-lto.patch
Looks like the problem is the assumption that the object file generated by 'gcc -c' will contain the binary representation of the code. This will be true for non-LTO builds or for LTO with -ffat-lto-objects. Since fat objects are disabled starting with GCC 4.9 the grep command is unable to find the expected binary data in the object file, which contains only GIMPLE.
There could be several ways to fix this. The attached patch modifies the test to produce a shared object instead of a plain object. This will invoke the linker and is guaranteed to produce a binary object regardless of the used CFLAGS.
yeah, I have the same error with gcc-4.9 and lto Created attachment 414492 [details, diff]
x264-0.0.20151011-lto.patch
Compiling without LTO or patching is still needed for x264-0.0-20151010
is this still valid with x264-0.0.20160712? (In reply to Pacho Ramos from comment #11) > is this still valid with x264-0.0.20160712? That is what I get as an error: [ebuild R ] media-libs/x264-0.0.20160712:0/148::gentoo USE="interlaced threads -10bit -opencl -pic -static-libs" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 1) media-libs/x264-0.0.20160712::gentoo * x264-snapshot-20160712-2245.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking x264-snapshot-20160712-2245.tar.bz2 to /tmp/portage/media-libs/x264-0.0.20160712/work >>> Source unpacked in /tmp/portage/media-libs/x264-0.0.20160712/work >>> Preparing source in /tmp/portage/media-libs/x264-0.0.20160712/work/x264-snapshot-20160712-2245 ... >>> Source prepared. >>> Configuring source in /tmp/portage/media-libs/x264-0.0.20160712/work/x264-snapshot-20160712-2245 ... * abi_x86_64.amd64: running multilib-minimal_abi_src_configure endian test failed * ERROR: media-libs/x264-0.0.20160712::gentoo failed (configure phase): * (no error message) * * Call stack: * ebuild.sh, line 115: Called src_configure * environment, line 2951: Called multilib-minimal_src_configure * environment, line 2128: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 2342: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2058: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2056: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 449: Called multilib-minimal_abi_src_configure * environment, line 2122: Called multilib_src_configure * environment, line 2561: Called die * The specific snippet of code: * "${S}/configure" --prefix="${EPREFIX}"/usr --libdir="${EPREFIX}"/usr/$(get_libdir) --disable-cli --disable-avs --disable-lavf --disable-swscale --disable-ffms --disable-gpac --enable-pic --enable-shared --host="${CHOST}" $(usex 10bit "--bit-depth=10" "") $(usex interlaced "" "--disable-interlaced") $(usex opencl "" "--disable-opencl") $(usex static-libs "--enable-static" "") $(usex threads "" "--disable-thread") ${asm_conf} || die * * If you need support, post the output of `emerge --info '=media-libs/x264-0.0.20160712::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-libs/x264-0.0.20160712::gentoo'`. * The complete build log is located at '/var/log/portage/media-libs:x264-0.0.20160712:20170420-131231.log'. * For convenience, a symlink to the build log is located at '/tmp/portage/media-libs/x264-0.0.20160712/temp/build.log'. * The ebuild environment file is located at '/tmp/portage/media-libs/x264-0.0.20160712/temp/environment'. * Working directory: '/tmp/portage/media-libs/x264-0.0.20160712/work/x264-snapshot-20160712-2245-abi_x86_64.amd64' * S: '/tmp/portage/media-libs/x264-0.0.20160712/work/x264-snapshot-20160712-2245' >>> Failed to emerge media-libs/x264-0.0.20160712, Log file: I downloaded the x264-0.0.20151011-lto.patch inside /etc/portage/patches/media-libs/x264, but no luck. I don't even see that the patch is applied. @Pacho Ramos Ok, I followed what is written in the [1]comments and now it applies the x264-0.0.20151011-lto.patch [1]http://dilfridge.blogspot.gr/2012/04/neat-trick-for-testing-patches-in.html post_src_unpack() { if type epatch_user >& /dev/null; then cd "${S}" epatch_user fi } .... >>> media-libs/x264-0.0.20160712 merged. So, it still works for x264. Should this patch be moved in to portage tree? =media-libs/x264-0.0.20170701 has --enable-lto in its options. I will test it again shortly. And it seems that it is prepared to detect it, for "$debug" = "no": if [ "$lto" = "auto" ] && [ $compiler = GNU ] && cc_check "" "-flto" ; then lto="yes" CFLAGS="$CFLAGS -flto" LDFLAGS="$LDFLAGS -O3 -flto" fi Issue with -flto . Should be set in USE flags? But using --enable-lto with -flto produce same error. It relies on configure to setup lto. Needs to be fixed in x264 code. This bug should be CONFIRMED. Created attachment 523910 [details, diff]
x264-0.0.20170701-lto.patch
I've successfully used an even simpler patch for media-libs/x264-0.0.20170701. It adds just a "-fno-lto" to the problematic configure test.
Still applies for x264-0.0.20170701, and last patch made it working with clang and LTO. I had not run into this before, but with the latest patch this problem now happens to me as well problem happens again with media-libs/x264-0.0.20190214; same patch as 0.0.20170701 allows test to pass. Can confirm that putting the patch in /etc/portage/patches/media-libs/x264 works on AMD64 with GCC 9.1.0 and x264-20190214. (In reply to Alexander Miller from comment #16) > Created attachment 523910 [details, diff] [details, diff] > x264-0.0.20170701-lto.patch > > I've successfully used an even simpler patch for > media-libs/x264-0.0.20170701. It adds just a "-fno-lto" to the problematic > configure test. Can you also meanwhile send it to upstream and reference your pull-request or sent patch here? :) Same issue happens with media-libs/x264-0.0.20190903 Same patch published here fixes it :) Still happens with latest x264 version and toolchain on arm; can we get the workaround in the tree and poke upstream? Created attachment 644640 [details, diff]
Newer patch to fix LTO configure bug
The buggy code in the configure file has been moved some row below.
The LTO problem is still present in x264-0.0.20190903-r1... and the old patch it's not working anymore, due to a change in configure file. I created a newer version of the patch :) x264-0.0.20190903-r1-lto.patch Iade Gesso, PhD (in Computer Science) The change in the configure file is caused by Sergei's Strings patch, that you can find here https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4531c7dc10670235bb6ff4658eb05f6081d4e205 It also broke gentooLTO's patch. This poses a patch ordering issue. We will probably copy Iade's fix :P *** Bug 695846 has been marked as a duplicate of this bug. *** This should be fixed in x264-0.0.20220222. |