[Ffmpeg-devel] [patch] building on windows

[Víctor Paesa]

Hi,

>>>>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 $^ $@
>>>>  else
>>>>  	ln -sf $^ $@
>>>>  endif
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
> this?
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.

Regards,
V?ctor Paesa