[FFmpeg-devel] Fix mingw name of .lib files
Thu Mar 6 12:04:59 CET 2008
M?ns Rullg?rd wrote:
> Gonzalo Garramu?o <ggarra at advancedsl.com.ar> writes:
> And then there's the FFmpeg build systems. It has everything FFmpeg
More likely, it has everything you need :).
With the building bugs addressed, it would probably bring me closer to
agreeing with you. BTW... is the git repository in sync? I'm not sure
I'm seeing the fix you put in.
I'll admit I would still like to be able to compile under MSVC. Not for
love of the platform but due to practical and potential technical issues.
Using mingw ffmpeg with msvc (say 7.1 or 8.0) forces to have two msvc
runtimes and I have seen msvc conflicts due to that (not with ffmpeg or
my current code but other projects). I know that issue is still
potentially lurking there (or perhaps ffmpeg does not get effected due
to being only C code??).
The msvc compiler and stdlib is usually much worse than gcc, but the
optimizer is often better (just as the intel compiler is often usually
better than both).
Finall the old msvc5 (?) runtime (ie. the one mingw uses) is old. The c
functions in that DLL are not threaded (or even thread safe, I believe),
which is slowly going to become another issue in the coming years.
> If the API has changed incompatibly, your code won't even compile.
> This has nothing to do with library versions. If your code compiles
> and links with a particular library version, it will not break at
> runtime (bugs aside).
I was thinking that you were suggesting to ship with say, v49, of my DLL
unversioned as avutil.dll. Under LGPL, problems arise.
User decides to enforce the LGPL and change his avutil.dll to a compiled
one by himself (say v50). His avutil.dll certainly compiles and his
ffplay works. Now, he tries it with my software. *BOOM* missing
function ff_XXX or some alignment issue (ie. crash).
Ergo, I ship all versioned. I guarantee all works with v49. User can
take advantage of LGPL but I only guarantee that to work with the branch
shipped. If he tries to use a newer (or older) ffmpeg lib, he is on his
own. It may still work, but can't do miracles.
Versioning is still important all the way to the user and back.
> When linking against the unversioned .lib file, the executable still
> gets a dependency on the versioned dll, just like in Unix linking
> against libfoo.so makes the executable depend on the DT_SONAME of that
> file, usually something like libfoo.so.17.
Right. As far as the *compiler/linker* is concerned. But what about
the packaging and distribution? How do I easily tell that code what DLL
version to ship from the several installed? Right now, the only way is
to use cygcheck (a non-ms tool of cygwin) or dependency walker (a ms
tool, more or less discontinued) on my exe, parse their non-standard
output and ship the libs. That also forces me to have the DLL in my
path also, so the tools can find it in the first place.
They are not good alternatives compared to the simple alternative of
just having my Makefile take the .lib filename that it linked to and
doing a simple regex of s/\.lib$/dll and copy the dll file somewhere for
On Linux land the issue is a little simpler due to the lack of .lib
files and the fact that LGPL .so files can be gotten by users with their
distro packet managers or from source (so I may not even need to really
To be more clear, I'm not against a .lib version (symlinked or not)
pointing to the latest version for easily finding and compiling. I'm
against not having a versioned .lib file *also* installed.
> Why would you care? New builds should be linked with the latest
> version, and the .lib files are not needed at runtime.
Besides packaging, I still foresee the need to know the lib->dll
relationship. Say, I ship v1.0 with avutil49, and v2.0 with avutil50.
User then wants a critical bug fixed for v1.0. I need to be able to
revert all the build to that and reship again with avutil49 (the code
may be too diverged to just upgrade to the new version -- plus I really
don't want to potentially get yet a new bug in there). Ideally, I would
hope that means not having to keep going back in svn history and
rebuilding ffmpeg each time or keep installing it in different
directories. Overwriting and having a single .lib file forces me to do
just that. I would prefer to just leave my /usr/local/lib and
/usr/local/bin with all versions of ffmpeg I shipped. Sure, avutil.lib
changes to point to v50, but old avutil-49.lib/dll is still v49 and a
> I care, because if symlinks don't work, users will come complaining
> that "make install" is broken.
Well, by that concept, make install is already broken under mingw32.
None of the installed .DLL files end up being symlinks (and, assuming
msys should work akin to unix, at the very least one of them should be).
I think this is something imaginary. I seriously doubt anyone can
expect you to actually fix problems with the OS or file system.
ggarra at advancedsl.com.ar
AMD4400 - ASUS48N-E
More information about the ffmpeg-devel