[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:
> 
>> Ramiro Ribeiro Polla wrote:
>>> What "every other library" do you mean?
>> Pretty much EVERY library built with autotools.  For example:
> 
> The autotools do crazy things on Unix too.  Just look at those .la
> files they insist on installing.  They are only ever used by libtool,
> and then only to cause trouble.  Do not use autotools as a reference
> for desirable behaviour.

.la files contain all the flags used to build the project and that only 
if you use libtool.  It makes perfect sense once you install a couple of 
files.

Any conflict that shows up is either a) user error or b) a bug in 
libtool (which were pretty common in the early days of autotools, but 
are more rare now).

I find it funny you hate autotools, as the ffmpeg build smells very much 
like a simpler (but functionally worse) copy of autotools.  I'm no fan 
of autotools myself but that's why I use cmake for my builds.

> Xiph are also not to be trusted.

Okay, I'll play along.  Who is to be trusted other than yourself?

> 
> On some systems, ldconfig creates symlinks from the SONAME of shared
> libs to the actual files, e.g. libfoo.so.1 -> libfoo.so.1.2.3.  The
> unversioned link selects the default version to use when compile-time
> linking, and is not used at all by the runtime linker.
> 

You are correct here about ldconfig (my bad).  The base symlinks are 
more often only created by distros when the developer package is loaded 
or manually by the user.

But that's my point.  I'm doing EXACTLY that behavior of unix in my 
build for windows, too.  For windows, I want to ship the *versioned* DLL 
of the libav* libs, so running my utility uses that *specific* version 
(to avoid user confusion or a program not working due to user changing 
to an incompatible ffmpeg --- which I know they will - LGPL, remember? )

But as it stands, I am now forced to find avcodec.lib and then 
(magically) realize I need to ship the avcodec-52.dll that happens to go 
with that avcodec.lib.  Which I can't do so reliably.   I can only find 
avcodec.dll reliably, which is no good.


>> but assuming that behavior is accepted,
> 
> It is not only accepted, it is intended.
> 

Accepted by who?  And intended to do what?  Drive users mad when they 
find they have avcodec.dll installed properly, but it just does not work 
with my software (because it is too old or too new)?

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.


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

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy