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

[Måns Rullgård]

Gonzalo Garramu?o <ggarra at advancedsl.com.ar> writes:

> M?ns Rullg?rd wrote:
>> 
>> I hate autotools because maintaining an autoconf/automake based build
>> system requires more effort than writing configure scripts and
>> makefiles by hand.  I'm speaking out of personal experience here.
>> 
>
> That I agree.  You have my sympathy if you need to maintain something 
> with autotools.  However these days there are other competing build 
> systems.  There's cmake (ugly syntax, but probably the more robust), 
> scons (python based somewhere in between), premake (tiny lua based for 
> small projects), etc.
> All of them are multi-platform (including native microsoft windows 
> toolchains, which is autotools real Achilles heel).  Cmake, afaik, is 
> really the only one with pretty solid cross-compiler support.

And then there's the FFmpeg build systems.  It has everything FFmpeg
needs.

>> Intended to allow multiple installed dll versions, without
>> complicating life for those wishing to link new apps with our
>> libraries.
>> 
>
> Okay.  So what happens when the API breaks (which in the time I've been 
> monitoring ffmpeg has already happened)?  If you are linking against a 
> non-versioned lib, all *might* work.  But it might also lead to 
> unexplicable crashes.

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 certainly prefer the failure to become obvious rather than getting a 
> user telling me their software crashes but used to work some other week.
>
>> If memory serves, attempting to run a Windows application with dlls
>> missing, will result in a message telling the user exactly which dlls
>> are required.  In the case libavcodec, that would be the versioned
>> name.
>> 
>
> *IF* you link against the versioned name (which is what I'm *trying* to 
> do easily) but not what you are proposing by having the .lib name being 
> unversioned.

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.

> The whole issue is that I'm trying to automate the release and I can't 
> because for linking with the microsoft compiler/mingw, you need to find 
> the lib file but for release you need to ship the correct DLL.  As the 
> lib name has no useful version, how am I to ship the right DLL?

I already told you of the cygcheck tool that comes with cygwin.  Use
it as-is, or do whatever it does yourself.

> Things will only get worse if, as you say, I need to support
> multiple versions. You are assuming versions just increase and you
> never have to support older versions.  Every time I compile ffmpeg,
> the avcodec.lib gets overwritten.  In a couple of months, I would
> then have no idea which version it belongs to anymore.

Why would you care?  New builds should be linked with the latest
version, and the .lib files are not needed at runtime.

>>> You keep repeating that but fail to provide an example of how this
>>> is helpful or why symlinks are not an acceptable (and much simpler)
>>> solution.
>> 
>> Last I checked, Windows had no notion of symlinks.
>> 
>
> Kind of.  There is something now for the past few years.  It is a pseudo 
> symlink called junctions since NT Server something.  XP has that too. 
> Vista improves upon that more and calls them symlinks (albeit they are 
> not).
> It is still not as good as unix symlinks but it might get there someday 
> :).  For file symlinks the big issue is that it has a limit on 32 
> symlinks per directory (yes, I know --- yuck).
>
> For mingw it really does not matter, as symlinks uses an old microsoft 
> runtime and they are still treated as hard links.  cygwin used to treat 
> symlinks as entries into its mount table in /etc/fstab and file symlinks 
> like mingw, IIRC.
>
> Overall, as the one doing the Makefile, do you care?  You just write "ln 
> -s".  What the underlying OS does with that it is up to the OS. 
> Hopefully, you get a symlink.  If not, well, worse that happens is you 
> get a hard link or a copy of the file.

I care, because if symlinks don't work, users will come complaining
that "make install" is broken.

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