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

[Måns Rullgård]

Gonzalo Garramu?o wrote:
> 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
>> needs.
>>
>
> More likely, it has everything you need :).

The difference being?

> With the building bugs addressed, it would probably bring me closer to

What bugs?

> agreeing with you.  BTW... is the git repository in sync?  I'm not sure
> I'm seeing the fix you put in.

The git repo is updated immediately on every svn commit.

> 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.

It is highly unlikely that we will ever support building with msvc.  If
you want to do that, you are on your own.

> 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??).

Windows dll hell is hardly our problem.

>> 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.

You obviously didn't read very carefully.

> 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.

You want to ship versioned dlls.  We build version dlls.  Where is the
problem?

>> 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
> distribution.

I'd say an explicit dependency check is the more reliable of those
options.

> 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
> ship them).

You could ask windows users to get ffmpeg separately too.  They'd
probably hate you for it, but that's again not our problem.

If distributing the right version is causing you so much worry, why
don't you link statically instead?  That removes the entire problem
of versioning, and gives you better performance at no extra cost.

>> 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
> stable one.

You'd still have to keep old versions of the header files around.  It
really would be much simpler for you to install each ffmpeg version in
a separate directory (configure --prefix).

>> 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.

Users come to us demanding exactly that all the time.  Search the
archives for stdint.h and see for yourself.

-- 
M?ns Rullg?rd
mans at mansr.com