[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