GNOME Bugzilla – Bug 324854
Library naming causes linking problems with MinGW
Last modified: 2006-06-06 19:31:39 UTC
The ffmpeg build currently doesn't seem to recongize MinGW properly. Only the static versions of libavformat and libavcodec are built, and they have a .lib file extension instead of a .a file extension. ffmepg.exe is built because it uses -L./libavformat -lavformat -L./libavcodec -lavcodec The gap executables fail to build, because the use an assumed absolute filename for the libs, e.g. "/c/usr/compile/gimp-gap/extern_libs/ffmpeg/libavformat/libavformat.a", which would be correct if the library file extensions would be .a Using relative paths like ffmpeg.exe would help to get around this problem, at least. (I'll file another bug for the problem of dynamic ffmpeg libs not getting built)
gap uses the static versions of libavformat and libavcodec for linking and therefore building of the dynamic versions is not done automatically. the configure.in file was changed in the current CVS version to support the .lib naming when build rund on MinGW. (but build on MinGW was not yet tested)
Hello Michael, I want to release gap-2.2.1 in a few days. Are there still build problems with libavformat/libavcodec on MinGW ?
Still the same problem.
2006-05-19 Sven Neumann <sven@gimp.org> * configure.in: added missing check for target architecture. Should fix bug #324854. Please test if this change fixes your problem and report back.
Created attachment 65933 [details] [review] get rid of the paths to libraries No, nothing did fix this so far. To clear up any misunderstandings, the library suffix is .a on MinGW, libavformat and libavcodec are the ones who do strange things here by adding .lib to their libraries. The linker in the MinGW distro does search for .lib as well, but only if you don't force to to link a non-existant .a, of course. Please check if the attached patch would be a valid solution and doesn't break the build on other platforms.
$LIBSUF was introduced just for the purpose to force linking with exactly those static built ffmpeg libraries that are built with .lib suffix (and avoid linking with another version of libavformat / libavcodec that may be installed in another directory.) Since gimp-gap uses a CVS snapshot of ffmpeg, (ffmpeg provides no recent stable releases) there may be plenty of ffmpeg library versions that are linkable with gimp-gap but will result in problems at runtime. (I think that also could be the reason why the prior gimp-gap release fails to encode any type of video on windows systems) As i can see from your report, the main problem is that detection of the target architecture does not yet work, because $LIBSUF has still the value .a on MinGW (instead of .lib as expected) I made another attempt to fix the detection of the target architecture in the configure.in script. With this fix the configure script now produces this output on my linux system: checking build system type... i686-suse-linux checking host system type... i686-suse-linux checking whether to enable maintainer-specific portions of Makefiles... yes checking for target architecture... i686-suse-linux checking for native Win32... no The output of the configure script in your windows environment could help for furter analysis if there are still build problems.
IMO you are trying to this this at the wrong place: - .a is the expectec library extension when using MinGW - libavformat and libavcodec should create .a files when built with MinGW
gimp-gap uses ffmpeg 1:1 as it is, and i see no chance to change the behaviour of ffmpeg for the planed gimp-gap release. Such changes could be discussed with the developers of ffmpeg, but based on the latest ffmpeg CVS version. (gimp-gap uses an older snapshot, and i dont know details about the latest CVS version yet.) There are plans to update gimp-gap to support a newer version of ffmpeg in the future and i will change to library suffix .a only if ffmpeg changes from .lib to .a too, but this change has very less priority for me. (I agree that .a would be the better solution) Does gimp-gap compile on MinGW after the fix in the latest CVS version ?
This bug is almost fixed, the libary extensions match the actual ones now. I've just discovered that the library files are just called avformat.lib avcodec.lib so something has to be done to allow for the missing 'lib' prefix as well.
A new fix was checked into CVS that uses both $LIBSUF and $LIBPREF in the configure.in script where windows environment has LIBPREF="" LIBSUF=".lib" UNIX environment LIBPREF="lib" LIBSUF=".a" this should refer to the correct names of the ffmpeg libraries and fix the build problem on windows.
Hello Michael, Does it work now with the current CVS version, or do we need another fix ?
Created attachment 66848 [details] [review] moved ${LIBPREF} one level down If the ${LIBPREF} is added at the right place (see attached patch), then this is fixed.
2006-06-06 Sven Neumann <sven@gimp.org> * configure.in: applied patch from Michael Schumacher to finally fix linking problems with MinGW (bug #324854).