GNOME Bugzilla – Bug 465924
bzip2 not built while it is present and usuable
Last modified: 2013-08-22 13:15:39 UTC
AC_CHECK_LIB (via AG_GST_CHECK_LIBHEADER) is used to detect bzip2. A generic prototype is used to check the lib (assuming the checked symbol is a cdecl function).
on linux and other unix, it's fine, but on windows, the test fails because of the decoration (@n).
I've ask an autoconf dev and he told me that the only way to check those libs on windows platform with MSYS/MinGW is to write a specific test, which includes the header and use AC_LINK_IFELSE
i don't really know how you want the check to be fixed. Maybe modifying the AG_GST_CHECK_LIBHEADER macro if it's on windows or not.
IMHO the best would be to fix AG_GST_CHECK_LIBHEADER() to always use AC_LINK_IFELSE, not only on Windows. Do you want to provide a patch and is this still a problem at all?
(In reply to comment #1)
> IMHO the best would be to fix AG_GST_CHECK_LIBHEADER() to always use
> AC_LINK_IFELSE, not only on Windows. Do you want to provide a patch and is this
> still a problem at all?
Then we can change the status to NEW.
Fixed in good/bad/libav now.
Author: Sebastian Dröge <email@example.com>
Date: Thu Aug 22 14:56:05 2013 +0200
configure: Fix bz2 configure check for Windows
Due to function decorations on Windows AC_CHECK_LIB can't be used to check for bz2.
Do note that this only applies to pristine upstream libbz2.
mingw.org patches bz2 to remove the use of stdcall convention. And THAT patch originates in Cygwin.
So both Cygwin and MinGW.org ship cdecl bz2.
I'm using that patch too, obviously.
Upstreaming this doesn't seem to be a likely prospect - for example, Debian still has to completely re-patch the whole bz2 buildsystem to use autotools properly, instead of a simple makefile; and they are usually very good at upstreaming...
Now, the change to configure is not going to break anything, so it's completely OK. This comment is mostly FYI.