[FFmpeg-devel] Fix mingw name of .lib files
Wed Mar 5 05:01:02 CET 2008
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
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
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
*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
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)
> 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
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.
ggarra at advancedsl.com.ar
AMD4400 - ASUS48N-E
More information about the ffmpeg-devel