I'm resuming my Quest to get the latest GStreamer compile for windows from my linux box trying to handle gst-ffmpeg. Things are going quite well, except with a problem with libtool I'll describe later.

Right now, gst-ffmpeg does not provide support for cross-compilation as it did in the past, the following patch tries to improve cross-compilation support:
    - if the configure script detects cross-compilation we should pass the --enable-cross-compile, --target-os, --arch and --cross-prefix switches to ffmpeg's configure script
    - the user can also provide extra switches to ffmpeg's configure script if you want to tune ffmpeg's build with --with-ffmpeg-extra-configure

Then, a few mingw32 specific things are needed, namely:
    - add --enable-memalign-hack
    - add -lws2_32 to the link (needed for ffmpeg's network functions)

So far, so good. Unfortunately it's not enough to get the whole plugin built. The issue is that linking a static library in a shared library is not portable (because there is no portable way to know is the static lib has been built with PIC objects) so libtool don't want to link av{codec,format,util}.dll into libgstffmpeg.dll.

On linux, libtool only prints a couple of warning and the lib gets built, but when compiling for mingw32 libtool refuses to incorporate static libs from a non-libtool library. It used to work with say gst-ffmpeg-0.10.2 because the internal ffmpeg lib was compiled with the autotools and thus a convenience library was built and used to link gstffmpeg.dll (see http://www.gnu.org/software/libtool/manual/html_node/Static-libraries.html for an explanation of what convenience libraries are)

The funny thing is: there is no such thing as PIC object in the windows world (mingw32 gcc ignores -fPIC) so not linking a DLL with a static lib should work and mingw32 libtool should allow it (issuing a warning about portability). I guess it could be considered as a libtool bug, there is one thread about this already: http://osdir.com/ml/gnu.libtool.general/2003-02/msg00127.html

So, what can be done ?

* "fix" it in libtool, saying that we can create a DLL with a static lib
* link with internal ffmpeg's shared libraries and ship them with libgstffmpeg
* use libtool again to build ffmpeg and use its convenience libraries to link libgstffmpeg
* use an ugly hack and and do a
 sed -i -e '/^deplibs_check_method=/s,".*","pass_all",' libtool
once gst-ffmpeg has been configured.

for now I'm using the later one, and it links !

-----------
As a quick summary, this is what I'm doing to get ffmpeg built from my linux box
(once the patch applied).

~/src/gst-ffmpeg-0.10.4$ cat ../build.env 
export CFLAGS=-I/opt/wombat/staging/i586-mingw32msvc/include
export LDFLAGS=-L/opt/wombat/staging/i586-mingw32msvc/lib
export PKG_CONFIG_LIBDIR=/opt/wombat/staging/i586-mingw32msvc/lib/pkgconfig
export PKG_CONFIG_PATH=/opt/wombat/staging/i586-mingw32msvc/lib/pkgconfig
~/src/gst-ffmpeg-0.10.4$ . ../build.env 
~/src/gst-ffmpeg-0.10.4$ ./configure  --prefix=/opt/wombat/staging/i586-mingw32msvc --host=i586-mingw32msvc  --disable-valgrind 
~/src/gst-ffmpeg-0.10.4$ sed -i -e '/^deplibs_check_method=/s,".*","pass_all",' libtool
~/src/gst-ffmpeg-0.10.4$ make

What do you think ?