Opened 10 years ago

Closed 9 years ago

#349 closed defect (fixed)

MingW32 Cross Compile of FFMPEG Fails

Reported by: Jose Santiago Owned by:
Priority: important Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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?

Attachments (4)

build-log-20110714.txt (90.1 KB ) - added by Jose Santiago 10 years ago.
Build Log Containing Cross Compile Failure
build-log-20110621.txt (92.7 KB ) - added by Jose Santiago 10 years ago.
Build Log from GIT HEAD 20110621 That Used to be successful
mingw-build-20120611.log (95.4 KB ) - added by Jose Santiago 9 years ago.
MINGW Build Log of FFMPEG GIT HEAD 20120611
ffmpeg-implib-install.patch (1.1 KB ) - added by John Stumpo 9 years ago.
My workaround, for reference.

Download all attachments as: .zip

Change History (14)

comment:1 by Carl Eugen Hoyos, 10 years ago

Priority: normalimportant
Status: newopen

This looks important.

comment:2 by Carl Eugen Hoyos, 10 years ago

Please add your configure line.

by Jose Santiago, 10 years ago

Attachment: build-log-20110714.txt added

Build Log Containing Cross Compile Failure

by Jose Santiago, 10 years ago

Attachment: build-log-20110621.txt added

Build Log from GIT HEAD 20110621 That Used to be successful

in reply to:  2 comment:3 by Jose Santiago, 10 years ago

Replying to cehoyos:

Please add your configure line.

See the attached logs:

build-log-20110714.txt - Failure calling lib.exe during install, not ignored.

build-log-20110621.txt - Ignores lib.exe failure during install

Version 1, edited 10 years ago by Jose Santiago (previous) (next) (diff)

comment:4 by Kyle, 10 years ago

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.

comment:5 by Michael Niedermayer, 9 years ago

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

by Jose Santiago, 9 years ago

Attachment: mingw-build-20120611.log added

MINGW Build Log of FFMPEG GIT HEAD 20120611

in reply to:  5 comment:6 by Jose Santiago, 9 years ago

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.

The issue seems to be that install cannot find 'libavcodec/avcodec.lib' . I think that about a year ago before this ticket was logged, this was not an error, but was a warning instead.

Last edited 9 years ago by Jose Santiago (previous) (diff)

comment:7 by dbuitenh, 9 years ago

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.

in reply to:  7 comment:8 by Kyle, 9 years ago

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.

comment:9 by John Stumpo, 9 years ago

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.)

by John Stumpo, 9 years ago

Attachment: ffmpeg-implib-install.patch added

My workaround, for reference.

comment:10 by Michael Niedermayer, 9 years ago

Resolution: fixed
Status: openclosed

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!

Note: See TracTickets for help on using tickets.