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

[Måns Rullgård]

Gonzalo Garramu?o wrote:
> M?ns Rullg?rd wrote:
>>>>
>>> More likely, it has everything you need :).
>>
>> The difference being?
>>
>
> You != me.

Thankfully.  However, you != FFmpeg too (thankfully), and my claim was
that the build system provides everything FFmpeg needs, with no mention
of you or me.

>> The git repo is updated immediately on every svn commit.
>>
>
> Cool.  So I'll assume your answer to the other thread about a fix being
> put in place was sarcasm with bad net etiquette.
>
> Please, Mans, while I do sometimes find your dry humor funny, while you
> are in the middle of a technical discussion with me, can I bother you to
> please make sure you mark your humor as such.  :) is just two
> keystrokes.  You just made me spend some minutes seeking for that fix in
> git.

Sorry, you lost me.  The fix is in both svn and git (as they are always
in sync).

>> I'd say an explicit dependency check is the more reliable of those
>> options.
>>
>
> In principle, yes.  In practice for this case, no, I'm afraid I don't
> agree there.
>
> Consider doing that in this case means writing a parser for the output
> format of a utility that is not really shipping with the os or target
> (neither mingw nor windows), is not compatible with utilities in unix
> land, whose source I may not even have (as depends.exe) and which scans
> a COFF format of microsoft that is, afaik, proprietary (albeit documented).

The output format you refer to is one filename per line, and source code
for cygcheck is readily available.  The object file format being specific
to Microsoft is hardly relevant, since you already rely on the linker
being able to produce it in the first place.

> vs...
>
> A Makefile whose source code I can see, uses only elements that ship
> with mingw/msys and will compile myself with a known dependency and that
> just requires a change that, at least to me, seems rather simple.

As you have seen, the actual binary dependencies might not be obvious
from the makefile.

>> If distributing the right version is causing you so much worry, why
>> don't you link statically instead?  That removes the entire problem
>> of versioning, and gives you better performance at no extra cost.
>>
>
> AFAIK, and correct me if I am wrong, that makes the code not be able to
> be LGPL (which is the ffmpeg licensing I've chosen for this project).

Reimar already answered this.

>> You'd still have to keep old versions of the header files around.  It
>> really would be much simpler for you to install each ffmpeg version in
>> a separate directory (configure --prefix).
>>
>
> That is a better argument.  Due to strict enforcing you do of LGPL, I

So you're saying if we didn't actively track down license violators,
you'd happily join their ranks?  Then I have no interest whatsoever
in helping you find a solution.

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