Summary: | media-video/ffmpeg-1.2.4 fails to build on loongson mips | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom Li <biergaizi2009> |
Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | mips |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | MIPS | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=583062 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
config.log |
Description
Tom Li
2013-12-29 04:43:39 UTC
...well ? Attach that config.log. Now I'm busy. I'll back to test it later on. I have very much doubt on distcc. Because of ffmpeg use the compiler to configure the source. But I need to confirm it. Will report back soon. 1) Please attach the entire build log to this bug report. 2) Please attach the file config.log from the top build directory to this bug report. *** Bug 496350 has been marked as a duplicate of this bug. *** Created attachment 366786 [details]
build.log
Created attachment 366788 [details]
config.log
build.log and config.log attached.
It seems
> error: '-mips32r2' conflicts with the other architecture options, which specify a mips3 processor
during configure cause the issue.
media-video/ffmpeg-1.2.3 also has the issue. media-video/ffmpeg-1.0.8 also has the issue. As well as media-video/ffmpeg-1.0.7. media-video/ffmpeg-0.10.10 works, too ancient version... Just about every single error looks the same: mips64el-unknown-linux-gnu-gcc -O2 -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -O2 -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -O2 -march=loongson2f -mplt -Wa,-mfix-loongson2f-nop -pipe -fomit-frame-pointer -mno-branch-likely -march=loongson2f -std=c99 -fomit-frame-pointer -fPIC -mips32r2 -mdsp -mdspr2 -mhard-float -c -o /var/tmp/portage/media-video/ffmpeg-1.2.4/temp/ffconf.pJZpt6hJ.o /var/tmp/portage/media-video/ffmpeg-1.2.4/temp/ffconf.a2ykCyPc.c Assembler messages: Error: -mips32r2 conflicts with the other architecture options, which imply -mips3 Warning: mips3 ISA does not support DSP ASE Warning: mips3 ISA does not support DSP R2 ASE Either ffmpeg configure script doesn't like your C{XX,PP}FLAGS (which look a bit fishy, btw.) or it doesn't support your hardware (by bug or choice). Now my temporary solution is using libav instead of ffmpeg. The latest version just build without any problem. I think if I remove -mips32r2 from ffmpeg's flags, it will build without problem, hum... does it work with $ EXTRA_FFMPEG_CONF="--disable-mips32r2" emerge -1 ffmpeg ? I think we should add the relevant useflags for these new mips optimisations then (In reply to Alexis Ballier from comment #15) > does it work with > $ EXTRA_FFMPEG_CONF="--disable-mips32r2" emerge -1 ffmpeg > > ? > > I think we should add the relevant useflags for these new mips optimisations > then Yes, it works. It just finished the configuration without any problem. :) (In reply to Alexis Ballier from comment #15) > does it work with > $ EXTRA_FFMPEG_CONF="--disable-mips32r2" emerge -1 ffmpeg > > ? > > I think we should add the relevant useflags for these new mips optimisations > then Is this related to #498082? The mips profiles are ISA agnostic. They only cover ABI, 32/64bits and endianness options. So these flags should be masked on per user basis. (In reply to Markos Chandras from comment #17) > (In reply to Alexis Ballier from comment #15) > > does it work with > > $ EXTRA_FFMPEG_CONF="--disable-mips32r2" emerge -1 ffmpeg > > > > ? > > > > I think we should add the relevant useflags for these new mips optimisations > > then > > Is this related to #498082? > The mips profiles are ISA agnostic. They only cover ABI, 32/64bits and > endianness options. So these flags should be masked on per user basis. yes it is, but so far it was automagically enabled and impossible to disable without the above command now that use.masks/unmasks are in place I'll backport them to the ~arch ebuilds |