GNOME Bugzilla – Bug 376591
configure.ac looks for wrong symbols for FAAD support
Last modified: 2007-03-01 08:38:40 UTC
Please describe the problem: In FAAD 2.5 (recently uploaded to Debian), faacDecOpen is a #define for NeAACDecOpen, thus the symbol is not found in the library. Steps to reproduce: 1. apt-get install libfaad-dev 2. ./configure --enable-faad 3. Read config.log. Actual results: configure:30385: checking for faacDecOpen in -lfaad configure:30415: gcc -o conftest -g -O2 conftest.c -lfaad -lm >&5 /tmp/ccsNVxRo.o: In function `main': /home/piman/code/debian/gst/gst-plugins-bad0.10-0.10.3/conftest.c:50: undefined reference to `faacDecOpen' collect2: ld returned 1 exit status Expected results: conigure.ac should check for a symbol that exists, or for either NeAACDecOpen or faacDecOpen, as GStreamer itself will compile fine since it actually includes the header. Is there some way to convince autoconf to make the generated test program include faad.h? Does this happen every time? Yes. Other information:
This is a problem due to the hack around '#include "gstfaad.h"' in ext/faad/gstfaad.c; as noted, the hack will need updating if the faad API changes. Unfortunately, the API seems to lack versioning.
Well, just detecting whether the NeAAC* or faac* functions should be used is easy enough for autoconf to figure out, and gstfaad.c can just #ifdef the right ones. So versioning is not needed for that. The bigger issue is the lack of shared object versioning, upgrading from FAAD < 2.5 to FAAD 2.5 will break already-compiled plugins, but that's not something GStreamer can or should try to work around. The 64-bit compatibility overrides don't seem to work anymore with FAAD 2.5 (NeAACDecInit2 fails). It fails both with and without the redefine hack, on my 32 bit system. I'm still exploring this. It would be good if someone who knew what that 64 bit compatibility bug was could look and see if it's still in 2.5.
Created attachment 76931 [details] [review] libfaad (<2.5) header patch for 64 bit systems
I can't reproduce the latter part of your last comment, it seems to work here. I attach the patch for AMD64 libfaad from Christian Marillat's Debian package repository. You are also removing the function prototypes as well as the redefines?
Amazing! FAAD finally (after 2 years or so) released an updated version with the changed symbols (so there's zero ABI compatibility, and only minimal API compatibility). But it still has the broken public headers! So we need an autoconf check (which I won't write) AND a similar-to-the-existing hack for the new API/headers. If someone wants to contribute an autoconf detection thing (that checks for the new header file - neaacdec.h instead of faad.h, and defines some appropriate preprocessor symbol), I'll see if I can hack up some further ugliness to make this work in the code. Meanwhile, please excuse me while I vomit over this code.
That patch is the 64-bit compatibility override for versions of FAAD previous to 2.5. It was included to inform JS. AFAIK, the 2.5 headers are entirely self consistent, and thus no symbol redefinition hack is needed. As I say, I cannot reproduce the problem JS is seeing. The NeAAC symbols and header file were introduced prior to FAAD 2.5 (possibly 2.0 release?).
The 2.5 release STILL has the broken headers (I checked this on friday), so the same hack (but for different symbols) is needed. I have not attempted to reproduce the reported problem, but the description matches what I would expect to happen.
The CVS of gst-plugins-bad build also against the faad with the NeAAC flavour. The fix will be in gst-plugins-bad-0.10.5. The patch below seems to be against faad itself. I don't se what we can do about this. Please file a new bug if neccesary.