After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 616194 - vorbisidec uses non public api
vorbisidec uses non public api
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal blocker
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-19 15:45 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2010-04-20 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-19 15:45:04 UTC
upstream vobisidec has no pkg-config script. If that is not available we check if 
vorbis_block_init is available. This is not a good idea as it is not public API
(see http://svn.xiph.org/trunk/Tremor/Version_script.in).

configure:27440: No package 'vorbisidec' found
configure:27471: checking for vorbis_block_init in -lvorbisidec
configure:27496: gcc -o conftest -g -O2   conftest.c -lvorbisidec   >&5
/tmp/ccAdfQWb.o: In function `main':
/home/ensonic/projects/gstreamer/gst-plugins-base/conftest.c:83: undefined reference to `vorbis_block_init'
collect2: ld returned 1 exit status
configure:27496: $? = 1
configure: failed program was:

Also the actual plugin uses that code.
Comment 1 Tim-Philipp Müller 2010-04-19 16:10:08 UTC
This is a known issue, I'm not sure it is a blocker though, there's no regression after all. If you have a non-intrusive fix, that can be considered of course.

I don't remember what the deal with this is, it looks like an upstream bug to me - it's in the header files after all. Not sure if there is any kind of upstream though..
Comment 2 Mark Nauwelaerts 2010-04-19 16:29:27 UTC
Indeed, it looks more like upstream needs some adjusting.  After all, it works :), is in header files, and using it mirrors the public API of mainstream vorbis, so why the alternate implementation feels like going different (or staying behind maybe) ?

Also, otherwise, iirc one would only be left with some (older) vorbisfile api or so, which is not quite so nice for vorbis(i)dec purposes.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-20 08:26:02 UTC
Okay, we're gettting upstream updates - I mark this as NOTGSTREAMER :)
http://lists.xiph.org/pipermail/vorbis-dev/2010-April/020148.html