[FFmpeg-devel] Fix mingw name of .lib files
Tue Mar 4 22:30:29 CET 2008
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.
> $ ls /usr/local/bin
Xiph are also not to be trusted.
>> What I was thinking when I made this change is "in Unix you do -lavutil,
>> in MSVC in you add avutil to the dependencies". But in Unix you can also
>> do -lavutil-xxx, so I agree with you that we should also be able to add
>> avutil-xxx to the dependencies.
>> IMO the best would be to install:
I see no reason at all to install the .lib file with full version
number. It would still be linking against the major-only dll.
> Yes. That's more standard, and more like Unix.
> Traditionally, under Linux, the basename with no version is something
> that ldconfig should be building and not the installer. But I don't
> think mingw has any concept of ldconfig (as windows does not really do
> versioning of DLLs).
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.
>> Which involves some deeper changes to the build system. Patches welcome
>> (by me, at least).
> It depends on what you want to do. The .lib files encode what DLL they
> were created for. Currently, ffmpeg install is just renaming the
> original avutil-52.lib without actually modifying the pointer in the
> .lib file.
> That is incorrect,
> but assuming that behavior is accepted,
It is not only accepted, it is intended.
mans at mansr.com
More information about the ffmpeg-devel