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 712811 - Don't use -DG_DISABLE_DEPRECATED flag
Don't use -DG_DISABLE_DEPRECATED flag
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: common
git master
Other Linux
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-21 14:00 UTC by Lionel Landwerlin
Modified: 2014-06-22 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
W32 gst: g_memmove() is deprecated (1.00 KB, patch)
2014-05-04 13:34 UTC, LRN 		committed Details | Review

Description Lionel Landwerlin 2013-11-21 14:00:16 UTC 
I stumbled upon a GStreamer compilation failure following the removal of g_memmove(). I've been told it's because of the G_DISABLE_DEPRECATED usage. It should be replaced by -DGLIB_VERSION_MIN_REQUIRED=...
Comment 1 Colin Walters 2013-11-21 14:23:10 UTC 
Fallout from https://bugzilla.gnome.org/show_bug.cgi?id=710519

Yep, this is breaking the build in gnome-continuous:

http://build.gnome.org/continuous/buildmaster/builds/2013/11/21/24/build/output.txt

G_DISABLE_DEPRECATED is itself basically deprecated.  We now use the GCC symbol-based deprecation stuff, which is just fundamentally better since it allows you to choose your particular version.

It doesn't work for macros, which is why you're now hitting this..but I think GLib consumers would be better off only injecting G_DISABLE_DEPRECATED occasionally than defaulting to on.
Comment 3 Tim-Philipp Müller 2013-11-21 14:36:38 UTC 
I think we kind of use this on purpose, so that we do get failures when something gets deprecated in the latest glib versions, and can fix it. We do want to do that as stuff gets deprecated and better API appears and not only when we bump the minimum requirement. As far as I can see we can't do that with the MIN_REQUIRED/MAX_ALLOWED system, can we?
Comment 4 Olivier Crête 2013-11-21 16:26:27 UTC 
In the same category, we should set GLIB_VERSION_MAX_ALLOWED to GLib 2.32 to make sure we don't use anything newer.
Comment 5 Tim-Philipp Müller 2013-11-21 16:32:17 UTC 
> In the same category, we should set GLIB_VERSION_MAX_ALLOWED to GLib 2.32 to
> make sure we don't use anything newer.

I think that's another thing that doesn't really work for us. If I remember correctly, if you set MAX_ALLOWED you can't even use newer API conditionally, and we often want to do that.
Comment 6 Tim-Philipp Müller 2013-11-21 16:33:02 UTC 
g_memmove() usage should be fixed in all main modules now btw.
Comment 7 Colin Walters 2013-11-21 17:02:47 UTC 
(In reply to comment #6)
> g_memmove() usage should be fixed in all main modules now btw.

Looks good to me, I've reverted the glib tag:
https://git.gnome.org/browse/gnome-continuous/commit/?id=13e311eaf44bb10658b2c23b92993fdfa157ff7a
Comment 8 Olivier Crête 2013-11-21 17:04:57 UTC 
@tim: We can just #undef MAX_ALLOWED in the files that want to use it. I'm more worried about unintended use.
Comment 9 LRN 2014-05-04 13:34:55 UTC 
Created attachment 275805 [details] [review]
W32 gst: g_memmove() is deprecated