MingW32 Cross Compile of FFMPEG Fails

[jlsantiago0]

I have a MingW32 cross toolchain for Win32 that used to work to cross-compile the GIT Head Through at least 20110621. I am not sure when it broke. The HOST is an OSX 10.6 and the target is MingW32. I am following the instructions to cross-compile for MingW32 under Linux and have been able to use this technique in the past to cross-compile for MingW32 under both Linux and MacOS.

I checked out the GIT HEAD today and found that now the build is calling LIB.EXE in cross-compile mode for instance:

lib.exe /machine:i386 /def:libavcodec/avcodec-53.def /out:libavcodec/avcodec.lib

I think this is a Microsoft Windows Application that is part of MSVC++. Is the intent now for cross-compiling for Windows to be dependent on LIB.EXE?

[cehoyos]

This looks important.

[cehoyos]

Please add your configure line.

[jlsantiago0]

Build Log Containing Cross Compile Failure

[jlsantiago0]

Build Log from GIT HEAD 20110621 That Used to be successful

[jlsantiago0]

Replying to cehoyos:

Please add your configure line.

See the attached logs:

build-log-20110714.txt - Failure during install

build-log-20110621.txt - install succeeds

It looks like the problem is this line in 20110621 used to succeed:

install -m 644 libavcodec/avcodec-53.lib "../bin/avcodec.lib"; install -m 644 libavcodec/avcodec-53.lib "../bin/avcodec-53.lib"; install -d "../lib"; install -m 644 libavcodec/libavcodec.dll.a "../lib/libavcodec.dll.a"

But in the latest GIT HEAD this command is run instead and fails:

install -m 644 libavcodec/avcodec.lib "../bin"
install: cannot stat `libavcodec/avcodec.lib': No such file or directory

So the issue description is not accurate. Looks like LIB.EXE has nothing to do with the failure.

[KSHawkEye]

I ran into this issue after updating as well.

I worked around it by creating the libs, and then make install (where previously I could make the libs after I make install).

It seems that FFmpeg won't install if it can not find the lib files, I'm not sure if it's only related to the shared aspect though.

Even if the lib.exe can not be found, and the lib files can not be created, I suggest that it does not break the make install. I also suggest that if the .lib files are made, that the .def files are not installed and only the .lib files are. You only need one or the other.

[michael]

I just tried a build under linux+mingw with --enable-shared --enable-static
I noticed no problem
So, is this issue still reproduceable ?

[jlsantiago0]

MINGW Build Log of FFMPEG GIT HEAD 20120611

[jlsantiago0]

Replying to michael:

I just tried a build under linux+mingw with --enable-shared --enable-static
I noticed no problem
So, is this issue still reproduceable ?

Yes. I have uploaded as an attachment the build log while building the latest FFMPEG GIT HEAD with MINGW.

[dbuitenh]

The problem is that configure should be calling the prefixed dlltool, and not "lib.exe". Libav's configure does this, but FFMpeg's does not, for some reason.

[KSHawkEye]

Replying to dbuitenh:

The problem is that configure should be calling the prefixed dlltool, and not "lib.exe". Libav's configure does this, but FFMpeg's does not, for some reason.

Looks like they use:

SLIB_EXTRA_CMD=-'$(DLLTOOL) -m $(LIBTARGET) -d $$(@:$(SLIBSUF)=.def) -l $(SUBDIR)$(SLIBNAME:$(SLIBSUF)=.lib) -D $(SLIBNAME_WITH_MAJOR)'

I second that we move over to dlltool if it can be used to create the .lib files.

I now recommend a cross compile environment to people wondering how to compile FFmpeg, and installing wine+Microsoft C++ Redistributable packages+lib.exe is a lot more work than simply using a MinGW-w64 dlltool.

If dlltool can create compatible .lib files, I strongly suggest using it.

[stump]

I'm running into this problem too, on current git master.

As an observation, libav switched to the dlltool line in  commit ec10a9ab and ffmpeg later reverted that in  commit 85c9365d, saying "this was requested by the windows experts / seems dlltool causes alot of problems".

This makes me think that an import library output by dlltool will still be incompatible with MSVC. Last time I tried linking to a MinGW-generated implib with MSVC, bad things happened (I'm not currently in a position to retry).

To work around this, in the script from which I cross-build ffmpeg, I hackishly patch library.mak (will attach patch for reference) to ignore the error installing the .lib file, just as the failure to invoke lib.exe is already ignored during make. (I don't consider make -k install to be a satisfactory solution, as that could hide real problems.) It looks like the mechanism I'm modifying is intended to be more general, but it looks like it's not used for anything other than installing the MSVC-compatible implibs for a mingw32 build. I think that if this import library incompatibility still exists, the right thing to do is probably to just ignore the error during install (or condition installation on the file's pre-existence).

(As another observation, if the binutils were indeed capable of making MSVC-compatible implibs, it would be possible to just pass -Wl,--out-implib,foo.lib while linking the DLLs and satisfy both MinGW and MSVC, as one of the expansions MinGW tries for -lfoo is foo.lib.)

[stump]

My workaround, for reference.

[michael]

Ive added support for dlltool, please test if it works for you, if not please reopen this issue and note, patches improving it are very welcome!