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 442065 - floatcast.h includes config.h and might break other apps
floatcast.h includes config.h and might break other apps
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal critical
: 0.10.15
Assigned To: Tim-Philipp Müller
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-05-29 13:49 UTC by Loïc Minier
Modified: 2007-09-25 11:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed fix (903 bytes, patch)
2007-05-31 16:41 UTC, Jan Schmidt
committed Details | Review

Description Loïc Minier 2007-05-29 13:49:20 UTC
Hi,

/usr/include/gstreamer-0.10/gst/floatcast/floatcast.h:#  include "config.h"

Severity is high since this can break other apps.

Bye,
Comment 1 Jan Schmidt 2007-05-31 16:41:59 UTC
Created attachment 89114 [details] [review]
proposed fix

I'm proposing we just remove the use of config.h

It means that any users (there aren't any, but anyway) of floatcast.h will end up taking the non-lrint option, but anything that's included config.h before floatcast.h like they should will get the same code they expect.
Comment 2 Jan Schmidt 2007-05-31 17:29:07 UTC
I'm not planning to put this in 0.10.13, btw - it's already in the 0.10.12 release and installed and we haven't had any complaints of broken apps, so I don't consider it a blocker.

We can fix it for 0.10.14, which is supposed to be out before Gnome 2.20.

Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2007-07-05 08:58:04 UTC
I am not sure what is meanth by "If optimisation is enabled" in the floatcast.h comment (but thats a different story).

What about applying the change now?
Comment 4 Sebastian Dröge (slomo) 2007-09-14 16:33:14 UTC
We could also generate the header by configure in theory... but I guess this is too ugly and we should just take the proposed patch. Anybody opposed to committing the patch?
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-25 07:28:28 UTC
Wouldn't it work if the application that uses floatcast.h includes config.h and in the macro docs we tell that the application that use those should check for the availability of lrint,lrintf ?
Comment 6 Tim-Philipp Müller 2007-09-25 11:56:17 UTC
> Wouldn't it work if the application that uses floatcast.h includes config.h and
> in the macro docs we tell that the application that use those should check for
> the availability of lrint,lrintf ?

Yes, I think it's the best we can do for now:


   2007-09-25  Tim-Philipp Müller  <tim at centricular dot net>

        * gst-libs/gst/floatcast/floatcast.h:
          Don't include config.h in an installed public header, this
          might break compilation of applications that don't have such
          a header and doesn't necessarily do what it's supposed to do
          anyway (ie. check for the lrint/lrintf defines) (#442065).
          Add docs for the various macros and document how this header
          has to be used (link against libm, etc.); add a few FIXMEs;
          include math.h for non-c99 code path.  Based on patch by
          Jan Schmidt.
          

Not that anything actually seems to use those gst_cast_*() macros ...