[Ffmpeg-devel] [patch] building on windows
Fri Jul 14 17:03:04 CEST 2006
>>>>Because of that users have to manually rename e.g. avcodec.dll.<number>
>>>>to avcodec.dll. The following patch fixes it.
>>>>--- old/common.mak 2006-07-13 16:17:56.000000000 0200
>>>> new/common.mak 2006-07-13 16:32:07.000000000 0200
>>>>@@ -18,7 18,11 @@ $(LIB): $(STATIC_OBJS)
>>>> $(RANLIB) $@
>>>> $(SLIBNAME): $(SLIBNAME_WITH_MAJOR)
>>>> ifeq ($(CONFIG_MINGW),yes)
>>>> cp -sf $^ $@
>>>> ln -sf $^ $@
What about creating a $(LN) variable, and setting it to either
'ln -sf' or 'cp -sf' in configure?
The Cygwin platform emulates links to some extent, but DLLs referenced
via links are not working, so it would be another platform to use $(LN).
> I was thinking that maybe using a patch that was suggested some while
> back (which changed the version number to before the .dll extension, as
> in libavutil.49.dll) is also a good solution. But, if we link with
> -lavutil, the executable will expect to find avutil.dll, and not
> avutil.49.dll (that's the problem at the moment, not finding correct
> file). I don't know much about how to do this, and how to go about doing
> it, but it would be good if the link argument pointed to the dll with
> version number. Either by linking with -lavutil.49 (I don't even know if
> this is possible, just a suggestion), or making the -lavutil argument
> look for avutil.49.dll, instead of avutil.dll. Anyone knows how to do
The Cygwin vhook/shared libraries patch I am working on ends up creating
a ffmpeg.exe the references libavutil.49.dll, the equivalent for MingGW
should be quite similar.
More information about the ffmpeg-devel