[FFmpeg-devel] Fix mingw name of .lib files
Fri Mar 7 12:59:28 CET 2008
M?ns Rullg?rd wrote:
>> More likely, it has everything you need :).
> The difference being?
You != 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
> I'd say an explicit dependency check is the more reliable of those
In principle, yes. In practice for this case, no, I'm afraid I don't
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).
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.
> 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).
> 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
will have to keep the ffmpeg source distro in my web server, so I don't
really need to keep sources on my disk unless I do have a bug to fix.
If I had to do it often, I'd keep libs disted as unix land in a single
dir and rely on using --incpath for headers with versioning, not
--prefix. This makes it easier for me to automate any changes later on
across platforms, as windows and unix file structures would look identical.
>> I think this is something imaginary. I seriously doubt anyone can
>> expect you to actually fix problems with the OS or file system.
> Users come to us demanding exactly that all the time. Search the
> archives for stdint.h and see for yourself.
Don't compare apples and oranges. I'm not planning to open that door.
stdint.h is a C99 requirement (which is clearly specified in the ffmpeg
page). Use of LIB files is not. It is mainly a windows requirement,
which you gently provide some support for in the makefile (appreciated).
If you follow microsofts approach to their own libraries, you find their
runtimes versioned with both the .lib and .dll with the same name (ie.
msvcr70.lib/msvcr70.dll), or no version name at all (ie. kernel.dll/lib
leading indeed to potential DLL hell).
Under MingW, lib files are optional (mingw gcc can link to DLLs directly
-- but linking will probably be faster with the lib files around). As
MinGW may be used for either coding directly to windows or as bridge to
GNU elements, you may see two camps there either traditionally sticking
to what's standard under windows/microsoft and those sticking a more
Unix (really, autotools) convention with MSYS.
ffmpeg currently installs LIB files (like microsoft needs) but I don't
think it follows any of those two conventions. It kind of leans more
towards behaving like autotools, but also not quite.
> You want to ship versioned dlls. We build version dlls. Where is the
No. I want versioned DLLs and corresponding versioned LIBs (ie.
something akin to what microsoft does with their msvcr71.lib and
I don't care either way for their unversioned ones (if you want to
install them, great too).
You build both files versioned, but install only unversioned LIBs.
Anyway, with all this discussion, you made me realize that the current
install procedure under mingw is also perhaps kind of backwards.
There's only the need to install a single versioned DLL (not multiple
ones as is now as neither the compiler nor linker nor runtime uses the
others) and there's the (at least my) need to install versioned LIBs
(which linkers and makefiles can indeed take advantage of).
I think the best procedure for me to avoid what seems like a
confrontation with you for a simple thing (and not have a nightmare in
maintainance with a complex work-around) is to just create my own
"Makefile.install" with an install rule according to my needs inside my
ffmpeg trunk. After all, the build part (which is the hard part of the
makefile) is done versioned. It's only the install that throws that
info away the part I don't agree with.
ggarra at advancedsl.com.ar
AMD4400 - ASUS48N-E
More information about the ffmpeg-devel