#1794 closed defect (invalid)
Can't cross-compile on Intel for ARM target with zmbvenc enabled
Reported by: | patters | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | zmbvenc |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I just checked this with the latest nightly source bz2 file and it's still a problem. I am compiling on a Ubuntu Desktop 12. I'm compiling for Synology NAS embedded systems that have multiple CPU architectures, using their various GCC toolchains available here:
http://sourceforge.net/projects/dsgpl/files/DSM%204.1%20Tool%20Chains/
Cross-compiling using their Intel toolchain is fine, so is cross-compiling for PowerPC-SPE (QorIQ). Only cross-compiling for ARM exhibits this problem (native compile is actually ok), and the issue can be circumvented by disabling the zmbv encoder at the configure stage.
Here is the error output:
... CC libavcodec/xwddec.o CC libavcodec/xwdenc.o CC libavcodec/xxan.o CC libavcodec/y41pdec.o CC libavcodec/y41penc.o CC libavcodec/yop.o CC libavcodec/yuv4dec.o CC libavcodec/yuv4enc.o CC libavcodec/zerocodec.o CC libavcodec/zmbv.o CC libavcodec/zmbvenc.o libavcodec/zmbvenc.c: In function 'encode_frame': libavcodec/zmbvenc.c:252: internal compiler error: internal consistency failure Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make: *** [libavcodec/zmbvenc.o] Error 1
Here's how I'm building:
cd ~/Downloads wget "http://sourceforge.net/projects/dsgpl/files/DSM%204.1%20Tool%20Chains/Marvell%2088F628x%20Linux%202.6.32/gcc421_glibc25_88f6281-GPL.tgz" tar xvzf gcc421_glibc25_88f6281-GPL.tgz sudo mv arm-none-linux-gnueabi /usr/local export TOOLCHAIN=/usr/local/arm-none-linux-gnueabi export AR=${TOOLCHAIN}/bin/arm-none-linux-gnueabi-ar export CC=${TOOLCHAIN}/bin/arm-none-linux-gnueabi-gcc export CXX=${TOOLCHAIN}/bin/arm-none-linux-gnueabi-g++ export LD=${TOOLCHAIN}/bin/arm-none-linux-gnueabi-ld export RANLIB=${TOOLCHAIN}/bin/arm-none-linux-gnueabi-ranlib export CFLAGS="-I${TOOLCHAIN}/include" export LDFLAGS="-L${TOOLCHAIN}/lib" export PKG_CONFIG_PATH="${TOOLCHAIN}/lib/pkgconfig" #-----fixed point maths modification for mpeg audio encoder sed -i "s/^#define USE_FLOATS//" libavcodec/mpegaudioenc.c ./configure --arch=arm --cpu=armv5te --enable-cross-compile --cross-prefix=${TOOLCHAIN}/bin/arm-none-linux-gnueabi- --target-os=linux --prefix=${TOOLCHAIN} --extra-cflags='-I${TOOLCHAIN}/include' --extra-ldflags='-L/tmp/lib' --enable-static --disable-shared --disable-ffplay --disable-ffserver --enable-pthreads make
Here's the toolchain's compiler version info:
Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /home/slava/toolchain_build/crosstool/build/arm-none-linux-gnueabi/gcc-4.2-glibc-2.5/gcc-4.2/configure --target=arm-none-linux-gnueabi --host=i686-host_pc-linux-gnu --prefix=/home/slava/toolchain_build/crosstool/install/gcc-4.2-glibc-2.5/arm-none-linux-gnueabi --with-tune=marvell-f --with-sysroot=/home/slava/toolchain_build/crosstool/install/gcc-4.2-glibc-2.5/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc --with-local-prefix=/home/slava/toolchain_build/crosstool/install/gcc-4.2-glibc-2.5/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc --disable-nls --enable-threads --with-gnu-as --with-gnu-ld --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --with-versuffix=CodeSourcery 2007q3-51, Marvell SoC SDK 2.1 --enable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch Thread model: posix gcc version 4.2.1
Change History (5)
comment:1 by , 11 years ago
Keywords: | cross-compile ARM removed |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 by , 11 years ago
Not being a developer I lack the expertise to do that unfortunately. I thought I'd open a ticket just in case it was something obvious to the experienced eye. Is there a typical thing to look for that would behave differently on native Vs cross compile?
comment:3 by , 11 years ago
I forgot: You could try --disable-debug, this may help.
(I was originally assuming that nobody works on such an old compiler anymore, the following tries to explain how to report the compiler bug in your case.)
Since the sourceforge page indicates that this toolchain may have active developers, you could try to report the compiler bug to them:
Run "make V=1 libavcodec/zmbvenc.o" to get the actual compiler command that produces the ICE (instead of "CC libavcodec/zmbvenc.o"), copy/paste and run that command to see that it is correct (it should produce the same ICE). Then replace "-c" (for "compile") by "-E" (preprocessing only) and test if you can reproduce the problem with only the preprocessed source:
.../.../gcc ... -c -o libavcodec/zmbvenc.o libavcodec/zmbvenc.c
->
.../.../gcc ... -E -o zmbvice.c libavcodec/zmbvenc.c
.../.../gcc -c zmbvice.c -o zmbvenc.o (you may have to add some of the original options here to reproduce the ICE, like "-g -O3 -fno-tree-vectorize", this step may also tell you how to avoid the crash)
If you still get the ICE, send the preprocessed file (zmbvenc.s) and the necessary gcc command to the toolchain developers. Perhaps they can fix the bug by updating the compiler (http://gcc.gnu.org/releases.html indicates it is over five years old).
If you only want to solve the compilation problem, I would assume the replacing "-O3" in the compile command by "-O1" (or -O2) could fix the ICE, just continue compilation with make to get executables.
follow-up: 5 comment:4 by , 11 years ago
Thanks for the tips. I've only just found time to look at it again. Compiling without the -g or the -fno-tree-vectorize didn't help, neither did -O2. Had to drop to -O1 to get it to compile. I'll pass a link to this page to the toolchain maintainer.
comment:5 by , 11 years ago
Replying to patters:
I'll pass a link to this page to the toolchain maintainer.
I suspect the only thing they would really need is the preprocessed source file (that should allow to reproduce the ICE).
Replying to patters:
I don't think there is anything the FFmpeg developers can do.
If you want to work on this issue, try to find the function (or line) in zmbvenc.c that causes the internal compiler error, a work-around might be possible and theoretically acceptable.