Opened 5 years ago

Closed 4 years ago

#349 closed defect (fixed)

MingW32 Cross Compile of FFMPEG Fails

Reported by: jlsantiago0 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 jlsantiago0 5 years ago.
Build Log Containing Cross Compile Failure
build-log-20110621.txt (92.7 KB) - added by jlsantiago0 5 years ago.
Build Log from GIT HEAD 20110621 That Used to be successful
mingw-build-20120611.log (95.4 KB) - added by jlsantiago0 4 years ago.
MINGW Build Log of FFMPEG GIT HEAD 20120611
ffmpeg-implib-install.patch (1.1 KB) - added by stump 4 years ago.
My workaround, for reference.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by cehoyos

  • Priority changed from normal to important
  • Status changed from new to open

This looks important.

comment:2 follow-up: Changed 5 years ago by cehoyos

Please add your configure line.

Changed 5 years ago by jlsantiago0

Build Log Containing Cross Compile Failure

Changed 5 years ago by jlsantiago0

Build Log from GIT HEAD 20110621 That Used to be successful

comment:3 in reply to: ↑ 2 Changed 5 years ago by jlsantiago0

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 5 years ago by jlsantiago0 (previous) (next) (diff)

comment:4 Changed 5 years ago by 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.

comment:5 follow-up: Changed 5 years ago by michael

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

Changed 4 years ago by jlsantiago0

MINGW Build Log of FFMPEG GIT HEAD 20120611

comment:6 in reply to: ↑ 5 Changed 4 years ago by 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.

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 4 years ago by jlsantiago0 (previous) (diff)

comment:7 follow-up: Changed 4 years ago by 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.

comment:8 in reply to: ↑ 7 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by 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.)

Changed 4 years ago by stump

My workaround, for reference.

comment:10 Changed 4 years ago by michael

  • Resolution set to fixed
  • Status changed from open to closed

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.