[FFmpeg-devel] I have discovered why many MinGW installs can no longer build ffmpeg
Chris Cormie
ccormie
Wed Aug 20 09:46:55 CEST 2008
Hi,
I'm new to ffmpeg development; hello everyone!
Back in April the ffmpeg makefiles were splendidly re-engineered by M?ns
Rullg?rd to be non-recursive (and and much rejoicing was heard
throughout the land, apparently.)
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-April/045168.html
At the time testers reported current MinGW installs failing to build
with the new makefiles. The poster's problem was resolved by changing
their version of make to a specific version: mingw32-make-3.81-2 (not
the current version). The cause of the problem wasn't found.
I have discovered a cause: MinGW make version 3.79.1 (and earlier?)
cannot handle calling a macro within a foreach statement. And this
construct is used by the new non-recursive makefiles.
Specifically:
define DOSUBDIR
$(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V))))
SUBDIR := $(1)/
include $(1)/Makefile
endef
$(foreach D,$(FFLIBS),$(eval $(call DOSUBDIR,lib$(D))))
Fails silently (ouch) -- the include statement is never executed. The
new system depends on the above code: the Makefiles in the
subdirectories include the toplevel subdir.mak where the rules for
building the libraries are located. This is why Axel Holzinger was
reporting "make: *** No rule to make target `libavdevice/libavdevice.a',
needed by `all'. Stop."
This is a bit of an issue because the (complex, error prone) official
MinGW installation instructions yield make 3.79.1
Some later versions of MinGW make can be shown not have this bug:
mingw32-make-3.81-2
make-3.81-MSYS-1.0.11-2.tar.bz2
But apparently the current release has different (breaking) bugs:
mingw32-make-3.81-20080326
This is a horrible situation for those of us trying to build ffmpeg on
MinGW. It would be good if we could put a note about the issue somewhere
-- perhaps in the README? I think a lot of people could be wasting
time over this one, given the "standard" MinGW install is affected.
I've also got a patch for configure that catches the 3.79.1 bug and
warns the developer (below.) Could this be considered for testing and
merging in?
Regards,
Chris Cormie
Index: configure
===================================================================
--- configure (revision 14784)
+++ configure (working copy)
@@ -221,7 +221,7 @@
solving the problem.
EOF
fi
- rm -f $TMPC $TMPE $TMPH $TMPO $TMPS $TMPSH
+ rm -f $TMPC $TMPE $TMPH $TMPO $TMPS $TMPSH $TMPM
exit 1
}
@@ -592,6 +592,13 @@
EOF
}
+check_make(){
+ log check_make "$@"
+ cat >$TMPM
+ log_file $TMPM
+ check_cmd make -f $TMPM
+}
+
require(){
name="$1"
header="$2"
@@ -1124,6 +1131,7 @@
TMPO="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.o"
TMPS="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.S"
TMPSH="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.sh"
+TMPM="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.mak"
check_cflags -fasm
check_cflags -std=c99
@@ -1262,6 +1270,7 @@
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME).$(LIBMAJOR)$(SLIBSUF)'
FFSERVERLDFLAGS=-Wl,-bind_at_load
objformat="macho"
+ enabled x86_64 && objformat="macho64"
;;
mingw32*)
target_os=mingw32
@@ -1561,6 +1570,7 @@
enabled_all x86_64 shared && append YASMFLAGS "-DPIC"
case "$objformat" in
elf) enabled debug && append YASMFLAGS "-g dwarf2" ;;
+ macho64) append YASMFLAGS "-DPIC -DPREFIX" ;;
*) append YASMFLAGS "-DPREFIX" ;;
esac
check_yasm "pabsw xmm0, xmm0" && enable yasm
@@ -1693,6 +1703,22 @@
EOF
done
+# Check for broken MinGW make
+check_make <<'EOF' || die "Broken make utility. If using MinGW try a
later version of make. make-3.81-MSYS-1.0.11-2 is known to work."
+define a
+ $(eval var = val)
+endef
+TEST_LIST = a b
+$(foreach D, $(TEST_LIST),$(eval($(call a))))
+all:
+ifeq ($(var),val)
+ @exit 0
+else
+ @exit 1
+endif
+EOF
+
+
# these are off by default, so fail if requested and not available
enabled avisynth && require2 vfw32 "windows.h vfw.h" AVIFileInit -lvfw32
enabled liba52 && require liba52 a52dec/a52.h a52_init -la52
More information about the ffmpeg-devel
mailing list