[FFmpeg-user] Unable to configure ffmpeg on FreeBSD
tevans.uk at googlemail.com
Wed Nov 7 18:13:04 CET 2012
On Wed, Nov 7, 2012 at 11:01 AM, Tom Evans <tevans.uk at googlemail.com> wrote:
> On Wed, Nov 7, 2012 at 10:16 AM, Tom Evans <tevans.uk at googlemail.com> wrote:
>> On Tue, Nov 6, 2012 at 5:21 PM, Tom Evans <tevans.uk at googlemail.com> wrote:
>>> Hi all
>>> I have a problem getting ffmpeg's configure to work properly when
>>> specifying "--cc" and "--as" on the configure line.
>>> What seems to happen is that configure thinks that the "--as" argument
>>> supplied is actually a c compiler, and tests to see if it is LLVM etc.
>>> This hangs, because 'as -v' prints the version and then waits for
>>> input ('cc -v' prints the version and exits).
>>>> $ ./configure --as=/usr/local/bin/as --cc=/usr/local/bin/gcc46 --extra-libs=-L/usr/local/lib --extra-cflags="-I/usr/local/include"
>>>> $ pstree 43143
>>> -+= 43143 tom /bin/sh ./configure --as=/usr/local/bin/as
>>> --cc=/usr/local/bin/gcc46 --extra-libs=-L/usr/local/lib
>>> |--- 43280 tom /usr/local/bin/as -v
>>> \--- 43281 tom grep -q ^gcc.*LLVM
>>> This check is around line 2486 in my current sources (pulled today):
>>>> $ grep -A 4 -B 1 -n gcc\.\*LLVM configure
>>> 2486: if $_cc -v 2>&1 | grep -q '^gcc.*LLVM'; then
>>> 2487- _type=llvm_gcc
>>> 2488- gcc_extra_ver=$(expr "$($_cc --version | head -n1)" : '.*\((.*)\)')
>>> 2489- _ident="llvm-gcc $($_cc -dumpversion) $gcc_extra_ver"
>>> 2490- _depflags='-MMD -MF $(@:.o=.d) -MT $@'
>>> I've tried re-ordering where --cc and --as appear, with no effect.
>>> There are no CC or AS environment variables set.
>> Having done a git bisect, the error was introduced in:
>> a758c5e2594893c0e7e1c5d966d6e486e2a77bb3 is the first bad commit
>> commit a758c5e2594893c0e7e1c5d966d6e486e2a77bb3
>> Author: Mans Rullgard <mans at mansr.com>
>> Date: Fri Jul 20 13:43:07 2012 +0100
>> build: do full flag handling for all compiler-type tools
>> This adds a full identification probe of CC, AS, LD and HOSTCC,
>> and sets up correct flags and dependency tracking for each.
>> Signed-off-by: Mans Rullgard <mans at mansr.com>
>> :100644 100644 478ffcab4b2bc3fe98fd62e852ef6f765bcd1796
>> 90b90fc18406b284db463c5e4e7019ce4d0bd4cf M Makefile
>> :100755 100755 c91b5f1ef2c057775d85b2d16884b3aab6c20db0
>> fd903692122baf0b3e16234974554e6987ab1dd8 M configure
>> I've not yet looked at the commit..
> So this commit abstracted out testing $cc to a function, probe_cc().
> For some reason, configure also calls probe_cc with $as and $ld, but
> the tests inside probe_cc are solely testing the compiler.
> The aim of calling probe_cc with $as arguments seems to be to set
> $as_type and $as_ident (also $ld_type and $ld_ident), which don't seem
> to be used elsewhere in the configure script at all. It just looks
> entirely bogus to me.
> Commenting out calls to 'probe_cc as "$as"' and 'probe_cc ld "$ld"'
> allow current git to configure correctly when supplied --as argument.
More fun and games. If I either comment out the call to "probe_cc as
$as", or modify probe_cc so that it does not do cc checks when passed
"as" as the type, this allows configure to complete. However, if I
supply --as *and* --cc, then compilation breaks further on in
There is no GPL 3 code allowed in the FreeBSD base toolchain, so if I
don't supply --as or --cc, then configure will use the stock version
of binutils/gcc, which on freebsd is old, and it is my understanding
that this produces slow/incorrect results when compiling h264_cabac.
To clarify, these are the versions in use:
OS: FreeBSD 9, amd64
Base: gcc 4.2.1 (FreeBSD patches) - binutils 2.17.50
User: gcc 4.6.4, gcc 4.7.3, binutils 2.22, yasm 1.2.0
--as=/usr/local/bin/as - libswscale builds OK
--as=/usr/local/bin/as --cc=/usr/local/bin/gcc46 - fails in
--as=/usr/local/bin/as --cc=/usr/local/bin/gcc47 - fails in
--cc=/usr/local/bin/gcc46 - libswscale builds OK
--cc=/usr/local/bin/gcc47 - libswscale builds OK
The failure (same in gcc46/gcc47):
# gmake distclean; ./configure --cc=/usr/local/bin/gcc46 ; gmake V=1
/usr/local/bin/gcc47 -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -DHAVE_AV_CONFIG_H -std=c99 -fomit-frame-pointer
-pthread -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include/SDL
-I/usr/local/include -g -Wdeclaration-after-statement -Wall
-Wno-parentheses -Wno-switch -Wno-format-zero-length
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls
-Wno-pointer-sign -Wwrite-strings -Wtype-limits -Wundef
-Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -O3
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize
-Werror=vla -MMD -MF libswscale/x86/swscale.d -MT
libswscale/x86/swscale.o -c -o libswscale/x86/swscale.o
libswscale/x86/swscale.c: In function 'yuv2yuvX_sse3':
libswscale/x86/swscale.c:214:9: error: implicit declaration of
function 'yuv2yuvX_MMXEXT' [-Werror=implicit-function-declaration]
libswscale/x86/swscale.c:214:9: warning: 'return' with a value, in
function returning void [enabled by default]
libswscale/x86/swscale.c: At top level:
libswscale/x86/swscale.c:209:13: warning: 'yuv2yuvX_sse3' defined but
not used [-Wunused-function]
cc1: some warnings being treated as errors
gmake: *** [libswscale/x86/swscale.o] Error 1
I think my understanding is wrong. Going back over emails on the same
topic in mplayer has reminded me that on amd64, as is not invoked
directly, gcc invokes it. How gcc invokes it depends on it's spec
file, inspecting this using "gcc -dumpspecs" shows that it no longer
has the full path to as there, therefore allowing PATH to come in to
play. Setting PATH so that the updated as is found first has solved
these problems I think.
I still think there is an error in the configure script in calling
"check_cc as $as". If anyone does pass in --as, the check will surely
hang - "as -v" does not exit after printing the version. I believe
this should be reproducible on any Linux box by configuring with
More information about the ffmpeg-user