[FFmpeg-devel] Fix mingw name of .lib files

Gonzalo Garramuño ggarra
Tue Mar 4 20:16:51 CET 2008


M?ns Rullg?rd wrote:
>>
>> instead of the, imo, broken:
>>
>> /usr/local/bin/avutil-52.dll
>> /usr/local/bin/avutil.lib
> 
> This is intentional.  With your proposal, users of the libs will have to
> know which version to link to, and change their makefiles whenever the
> version number changes.
> 

No, it is the other way around.  The problem *now* is that you need to 
know what to link against.  The avutil.lib name does not change, but the 
name of the DLL to link against does, regardless of how avutil is named. 
(ie. when linking against a shared ffmpeg - static linking is no issue 
of course),

The executable does not link against avutil.dll, but to a specific 
version, like avutil-52.dll.

This means that distribution of the executable becomes a pain, as you 
really cannot tell which DLL to distribute easily from a makefile.  You 
have to actually analyze the resulting .exe and make sure the DLL is in 
the path (a royal pain).

If you want to have users not worry about versioning at all on windows 
(a bad idea if you ask me, but I'll go along with it), then both the 
.lib file and the .dll should not be versioned.  Or a symlink (a copy on 
windows really) should be made on install.

Having one versioned but not the other is really what makes it a royal pain.

Personally, I strongly disagree about not versioning stuff, as it makes 
harder to know why something is broken.  And if you are using a 
mingw/msys only system, it goes against the grain of Unix, which is a 
no-no in my book.

Also, using ffmpeg normally, you really do not have to worry about 
versioning as the Makefile takes care of it.

What you have right now is something that ONLY simplifies static 
linking, as there is no need to know the ffmpeg version.


-- 
Gonzalo Garramu?o
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy




More information about the ffmpeg-devel mailing list