Message ID | 87zh3jkggf.fsf@gmail.com |
---|---|
State | New |
Headers | show |
Series | [FFmpeg-devel,v2] configure: fix the bigendian test | expand |
Context | Check | Description |
---|---|---|
andriy/x86_make | success | Make finished |
andriy/x86_make_fate | success | Make fate finished |
andriy/PPC64_make | success | Make finished |
andriy/PPC64_make_fate | success | Make fate finished |
Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > There are two issues: > > When build systems enable LTO in CFLAGS, the unused global integer > does not make it into the compiled object file. As a workaround, > check if the compiler understands -fno-lto and append it after > CFLAGS while building the endianness test. > > The hexdump output is line-wrapped, so the expected value will not > be matched when its four bytes are split across two lines. Use the > POSIX "-A n" option to disable printing input offsets and delete > all newline characters to output continuous hex values to grep. Please explain how we can reproduce the issue (configure line, compiler, os). Carl Eugen
On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > > > There are two issues: > > > > When build systems enable LTO in CFLAGS, the unused global integer > > does not make it into the compiled object file. As a workaround, > > check if the compiler understands -fno-lto and append it after > > CFLAGS while building the endianness test. > > > > The hexdump output is line-wrapped, so the expected value will not > > be matched when its four bytes are split across two lines. Use the > > POSIX "-A n" option to disable printing input offsets and delete > > all newline characters to output continuous hex values to grep. > > Please explain how we can reproduce the issue (configure line, > compiler, os). It's the same command I sent you for the v1 patch. Just configure it to cross-compile to a big-endian target with CFLAGS=-flto in the environment: CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc --arch=powerpc --target-os=linux --cross-prefix=powerpc-unknown-linux-gnu- Thanks. David
Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > > > > > There are two issues: > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > does not make it into the compiled object file. As a workaround, > > > check if the compiler understands -fno-lto and append it after > > > CFLAGS while building the endianness test. > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > be matched when its four bytes are split across two lines. Use the > > > POSIX "-A n" option to disable printing input offsets and delete > > > all newline characters to output continuous hex values to grep. > > > > Please explain how we can reproduce the issue (configure line, > > compiler, os). > > It's the same command I sent you for the v1 patch. Just configure it > to cross-compile to a big-endian target with CFLAGS=-flto in the > environment: > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > --arch=powerpc --target-os=linux > --cross-prefix=powerpc-unknown-linux-gnu- Is the issue reproducible if you configure with "--enable-lto" instead of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? Carl Eugen
On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > > > > > > > There are two issues: > > > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > > does not make it into the compiled object file. As a workaround, > > > > check if the compiler understands -fno-lto and append it after > > > > CFLAGS while building the endianness test. > > > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > > be matched when its four bytes are split across two lines. Use the > > > > POSIX "-A n" option to disable printing input offsets and delete > > > > all newline characters to output continuous hex values to grep. > > > > > > Please explain how we can reproduce the issue (configure line, > > > compiler, os). > > > > It's the same command I sent you for the v1 patch. Just configure it > > to cross-compile to a big-endian target with CFLAGS=-flto in the > > environment: > > > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > > --arch=powerpc --target-os=linux > > --cross-prefix=powerpc-unknown-linux-gnu- > > Is the issue reproducible if you configure with "--enable-lto" instead > of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? There is no failure when it has empty CFLAGS and --enable-lto since that adds -flto after the endianness test. If it is expected that ffmpeg will break from CFLAGS, then I guess I can pursue this at the distro packaging level. Thanks. David
On Sat, Nov 14, 2020 at 8:21 PM David Michael <fedora.dm0@gmail.com> wrote: > On Sat, Nov 14, 2020 at 6:57 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > Am Sa., 14. Nov. 2020 um 20:16 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > > On Sat, Nov 14, 2020 at 2:06 PM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > > Am Sa., 14. Nov. 2020 um 18:22 Uhr schrieb David Michael <fedora.dm0@gmail.com>: > > > > > > > > > > There are two issues: > > > > > > > > > > When build systems enable LTO in CFLAGS, the unused global integer > > > > > does not make it into the compiled object file. As a workaround, > > > > > check if the compiler understands -fno-lto and append it after > > > > > CFLAGS while building the endianness test. > > > > > > > > > > The hexdump output is line-wrapped, so the expected value will not > > > > > be matched when its four bytes are split across two lines. Use the > > > > > POSIX "-A n" option to disable printing input offsets and delete > > > > > all newline characters to output continuous hex values to grep. > > > > > > > > Please explain how we can reproduce the issue (configure line, > > > > compiler, os). > > > > > > It's the same command I sent you for the v1 patch. Just configure it > > > to cross-compile to a big-endian target with CFLAGS=-flto in the > > > environment: > > > > > > CFLAGS=-flto ./configure --enable-cross-compile --host-cc=gcc > > > --arch=powerpc --target-os=linux > > > --cross-prefix=powerpc-unknown-linux-gnu- > > > > Is the issue reproducible if you configure with "--enable-lto" instead > > of CFLAGS (I suspect FFmpeg does not support CFLAGS in general)? > > There is no failure when it has empty CFLAGS and --enable-lto since > that adds -flto after the endianness test. If it is expected that > ffmpeg will break from CFLAGS, then I guess I can pursue this at the > distro packaging level. Oh, but ffmpeg should still probably apply the second half of the patch to work with split lines. I did encounter a failure from that a couple days ago. Thanks. David
diff --git a/configure b/configure index 51e43fbf66..47160b4bbc 100755 --- a/configure +++ b/configure @@ -5756,10 +5756,11 @@ done check_cc pragma_deprecated "" '_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")' # The global variable ensures the bits appear unchanged in the object file. -test_cc <<EOF || die "endian test failed" +test_cflags -fno-lto && override_flags=-fno-lto || override_flags= +test_cc $override_flags <<EOF || die "endian test failed" unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E'; EOF -od -t x1 $TMPO | grep -q '42 *49 *47 *45' && enable bigendian +od -A n -t x1 $TMPO | tr -d '\n' | grep -q '42 *49 *47 *45' && enable bigendian check_cc const_nan math.h "struct { double d; } static const bar[] = { { NAN } }"
There are two issues: When build systems enable LTO in CFLAGS, the unused global integer does not make it into the compiled object file. As a workaround, check if the compiler understands -fno-lto and append it after CFLAGS while building the endianness test. The hexdump output is line-wrapped, so the expected value will not be matched when its four bytes are split across two lines. Use the POSIX "-A n" option to disable printing input offsets and delete all newline characters to output continuous hex values to grep. Signed-off-by: David Michael <fedora.dm0@gmail.com> --- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)