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

[Gonzalo Garramuño]

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

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

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

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


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

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy