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

[Gonzalo Garramuño]

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.

>>> Xiph are also not to be trusted.
>> Okay, I'll play along.  Who is to be trusted other than yourself?
> 
> Anyone who does things the simple, Unix way.
> 

I was looking for an example project that builds libraries like ffmpeg 
does to understand the merits.

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

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.

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

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

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

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy