GNOME Bugzilla – Bug 729190
error when building libvpx on windows: redefinition of `CONFIG_VP8'
Last modified: 2016-04-25 06:35:30 UTC
cerbero build for windows 64bit fails with the following errors ( by skipping the broken recipes ) [CC] vpx_config.c.o vpx_config.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default] [AS] vpx_ports/emms.asm.o vpx_config.asm:54: error: redefinition of `CONFIG_VP8' vpx_config.asm:53: error: `CONFIG_VP8' previously defined here make[1]: *** [vpx_ports/emms.asm.o] Error 1 make: *** [.DEFAULT] Error 2 Running command 'make HAVE_GNU_STRIP=no' ---------------------------------------------------- /bin/sh ../libtool --silent --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -Wall -g -O2 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -Wall -g -MT enc_output.lo -MD -MP -MF .deps/enc_output.Tpo -c -o enc_output .lo enc_output.c mv -f .deps/enc_output.Tpo .deps/enc_output.Plo /bin/sh ../libtool --silent --tag=CC --mode=link x86_64-w64-mingw32-gcc -Wall -g -O2 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -Wall -g -version-info 4:3:0 -no-undefined -Lc:/gstreamer/1.0/x86_64/lib -lpthread -o libdv.la -rpath /c/g streamer/1.0/x86_64/lib dv.lo dct.lo idct_248.lo weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo YV12.lo rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo enc_audio_input.lo enc_output.lo -lpthread -lm c:/mingw/msys/1.0/home/admin/cerbero/mingw/w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -link collect2.exe: error: ld returned 1 exit status make[3]: *** [libdv.la] Error 1 make[3]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/libdv-1.0.0/libdv' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/libdv-1.0.0/libdv' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/libdv-1.0.0' make: *** [all] Error 2 Running command 'make' Recipe 'libdv' failed at the build step 'compile' ----------------------------------------------------- libtool: link: x86_64-w64-mingw32-gcc -o .libs/libgstalpha.dll.a .libs/libgstalpha_la-gstalpha.o -mms-bitfields -mms-bitfields -mms-bitfields -O2 `func_echo_all " -Lc:/gstreamer/1.0/x86_64/lib -lpthread -L=c:/gstreamer/1.0/x86_64 /lib -L==c:/gstreamer/1.0/x86_64/lib -L===c:/gstreamer/1.0/x86_64/lib -L/c/gstreamer/1.0/x86_64/lib /c/gstreamer/1.0/x86_64/lib/libgstvideo-1.0.dll.a -L====c:/gstreamer/1.0/x86_64/lib /c/gstreamer/1.0/x86_64/lib/liborc-0.4.dll.a /c/gs treamer/1.0/x86_64/lib/libgstbase-1.0.dll.a /c/gstreamer/1.0/x86_64/lib/libgstreamer-1.0.dll.a /c/gstreamer/1.0/x86_64/lib/libgmodule-2.0.dll.a /c/gstreamer/1.0/x86_64/lib/libgobject-2.0.dll.a /c/gstreamer/1.0/x86_64/lib/libffi.dll.a /c/gstreamer/1.0/x86_64/lib/libglib-2.0.dll.a -lws2_32 -lole32 -lwinmm -lshlwapi /c/gstreamer/1.0/x86_64/lib/libintl.dll.a" | /usr/bin/sed 's/ -lc$//'` -link -dll c:/mingw/msys/1.0/home/admin/cerbero/mingw/w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -link collect2.exe: error: ld returned 1 exit status make[3]: *** [libgstalpha.la] Error 1 make[3]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/gst-plugins-good-1.0-1.3/gst/alpha' make[2]: *** [alpha] Error 2 make[2]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/gst-plugins-good-1.0-1.3/gst' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/home/admin/cerbero/sources/windows_x86_64/gst-plugins-good-1.0-1.3' make: *** [all] Error 2 Running command 'make' Recipe 'gst-plugins-good-1.0' failed at the build step 'compile' * this might all be because msgmerge is failing with: "The procedure entry point rpl_memchr could not be located in the dynamic link library c:\mingw\bin\msgmerge.exe. "
I can reproduce the libvpx problem here. It works just fine from the 1.2 branch in the same build tree, but fails with master (even when reverting the libvpx recipe back to 1.2 version). Something in how cerbero builds stuff must've changed. The relevant code for this is in configure and build/make/configure.sh. It's not clear to me how CONFIG_VP8 can appear multiple times here, unless the shell used by configure is broken. It is generated from $CODECS_FAMILIES: > CODECS="$(echo ${CODECS} | tr ' ' '\n')" > CODEC_FAMILIES="$(for c in ${CODECS}; do echo ${c%_*}; done | sort | uniq)" CODECS is "vp8_encoder and vp8_decoder" and running that command manually in a shell gives the expected result of a single "vp8".
So the issue seems to be related to how subprocess and stdout/stderr redirection worked on windows. That eventually caused havoc with the subprocess environment. I've committed a patch that disables that feature on windows and everything moves on fine (libvpx, libdv, gst-plugins-good). Leaving the bug open so someone can investigate deeper into the issue. commit a86b1f5dd5dc5057f3b2beea023891cb0ee04969 Author: Edward Hervey <bilboed@bilboed.com> Date: Mon May 19 15:12:50 2014 +0200 shell: Don't ask too much from windows Handling redirections is a bit too complicated for windows, so let's not push the old fellow too much and just disable output redirection. https://bugzilla.gnome.org/show_bug.cgi?id=729190
I have seen this error before, but it was fixed misteriously after restarting the shell. For some reason libtool ends up assuming we are using a MSVC wrapper ans sets incorrectly archive_cmds: 5162 *) 5163 # Assume MSVC wrapper 5164 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' ' 5165 _LT_TAGVAR(allow_undefined_flag, $1)=unsupported 5166 # Tell ltmain to make .lib files, not .a files. 5167 libext=lib 5168 # Tell ltmain to make .dll files, not .so files. 5169 shrext_cmds=".dll" 5170 # FIXME: Setting linknames here is a bad hack. 5171 _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags `func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='
libvpx does not use libtool (or autotools) though
I have seen that as well, but not for a while. Has anyone else seen it recently? If not maybe we should close this until it happens again?