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

I've lost count of the number of times I've had to patch .la files to
make things work properly.  Thankfully, Gentoo can do it automatically
in many cases, but that doesn't alter the fact libtool is doing
something that shouldn't be done, and doing it badly to boot.

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

libtool itself is a bug the size of a planet, and it grows with each
release.

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

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.

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

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

The FFmpeg build system creates a versioned dll.  What's your problem?

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

Cygwin comes with a nifty tool called cygcheck that will list all dll
dependencies of an executable, much like ldd does on many Unix-type
systems.  I think it even works without having cygwin installed.

>>> but assuming that behavior is accepted,
>> 
>> It is not only accepted, it is intended.
>> 
>
> Accepted by who?

Everybody but you, it seems, including in particular the FFmpeg win32
maintainers.

> And intended to do what?

Intended to allow multiple installed dll versions, without
complicating life for those wishing to link new apps with our
libraries.

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

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.

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

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