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 560442 - GNOME Goal: Remove deprecated GLib symbols
GNOME Goal: Remove deprecated GLib symbols
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.10.26
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 560423
 
 
Reported: 2008-11-12 02:50 UTC by Luis Menina
Modified: 2009-12-21 02:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Removes deprecated win32-compatibility function (1.48 KB, patch)
2009-06-16 20:33 UTC, LRN
committed Details | Review
Use g_mapped_file_unref (1.42 KB, patch)
2009-12-03 18:51 UTC, Javier Jardón (IRC: jjardon)
committed Details | Review

Description Luis Menina 2008-11-12 02:50:50 UTC
See http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/Glib
Here are the files+lines using deprecated GLib symbols in this module:

gstreamer/tests/old/testsuite/caps/intersection.c:60:     g_mem_chunk_info ();
gstreamer/tests/old/testsuite/caps/intersection.c:65:     g_mem_chunk_info ();
gstreamer/tests/old/testsuite/plugin/loading.c:15:  g_mem_chunk_info ();
gstreamer/tests/old/testsuite/plugin/loading.c:33:  g_mem_chunk_info ();
gstreamer/tests/old/testsuite/plugin/loading.c:52:  g_mem_chunk_info ();
Comment 1 Edward Hervey 2008-11-12 14:23:44 UTC
Those are:
* Not used in distributed code (since they're tests)
* Those tests aren't even used nowadays (they were for 0.8)

Luis, Are those two reasons acceptable for marking this bug as NOTABUG ?

Regarding your testing logic, you might want to figure out if the symbols are used in the *compiled* binaries/libraries instead of the code.
Comment 2 Luis Menina 2008-11-12 16:44:22 UTC
As there's an awful *lot* of modules to check (the whole GNOME stack, and some external dependencies too), I'm using egrep to find the symbols, doing some kind of static analysis. Doing so makes easier for newcommers to contribute to the GNOME Goals: they don't need to compile a module to know wether a module uses deprecated symbols or not. I can also tell them which module they can fix, without building the whole GNOME stack myself.

Static analysis is much also much faster: calling 'jhbuild update' and then egrep to find deprecated symbols allows me to easily know the state of each module. Compare this to the time required to build the whole GNOME stack... 

I understand that removing "false positives" (comments, calls in dead code) can be seen as tedious and useless, because it's not a "bug". But doing so will make subsequent checks easier, making GNOME 3.0 transition smoother (this goal concerns GLib, but the same will be applied to GTK, GDK, and gdk-pixbuf in another GNOME Goal).

The only workaround I could see is to use the build brigade to compile GNOME with deprecated symbols disabled by default, and have them notify people when the build breaks. But results may vary, according to build options, and it become harder to involve people that way...

In conclusion, if your tests are neither used nor distributed, why don't you drop them ? SVN will keep them for you in case you need to pick some stuff from there. But is there really a good reason to keep them around ?
Comment 3 Wim Taymans 2008-11-13 18:03:22 UTC
        * tests/old/testsuite/caps/intersection.c: (main):
        * tests/old/testsuite/plugin/loading.c: (main):
        Remove references to deprecated API g_mem_chunk*.
        Fixes #560442.
Comment 4 André Klapper 2009-06-14 18:08:34 UTC
Reopening - according to http://www.gnome.org/~fpeters/299.html this module currently contains one deprecated GLib symbol.

See http://library.gnome.org/devel/glib/stable/glib-Windows-Compatibility-Functions.html#g-win32-get-package-installation-directory
Note that the substitute requires GLib 2.16.

List of deprecated symbols:
"g_win32_get_package_installation_directory"

./gst/gst.c:      base_dir = g_win32_get_package_installation_directory (NULL,

See http://library.gnome.org/devel/glib/stable/glib-Windows-Compatibility-Functions.html#g-win32-get-package-installation-directory
Note that the substitute requires GLib 2.16.
Comment 5 Sebastian Dröge (slomo) 2009-06-14 18:16:28 UTC
We can't depend on GLib 2.16 at this point so this bug needs to stay open for some more months unfortunately
Comment 6 Tim-Philipp Müller 2009-06-14 19:10:23 UTC
We already depend on GLib 2.16 in git master.

I guess we'd need someone with a win32 setup to add a DllMain function so we can save the handle, and actually test that code.

Comment 7 LRN 2009-06-16 20:33:32 UTC
Created attachment 136771 [details] [review]
Removes deprecated win32-compatibility function

Adds DllMain, which stores the HMODULE, which is later used to get GStreamer installation directory with g_win32_get_package_installation_directory_of_module().

Builds correctly. Seems to be working correctly too (tested on gst-launch and gst-inspect)
Comment 8 Tim-Philipp Müller 2009-06-17 08:58:18 UTC
LRN: thanks!


 commit 7ad8d2e54c36962f1379d245398dc2f9d52ee600
 Author: Руслан Ижбулатов <lrn1986@gmail.com>
 Date:   Wed Jun 17 00:29:40 2009 +0400

    Replaced deprecated win32-compatibility function with undeprecated one.
    
    Fixes #560442.
Comment 9 Javier Jardón (IRC: jjardon) 2009-12-03 18:50:13 UTC
Reopening - according to http://www.gnome.org/~fpeters/299.html this module
currently contains one deprecated GLib symbol: g_mapped_file_free
Comment 10 Javier Jardón (IRC: jjardon) 2009-12-03 18:51:24 UTC
Created attachment 149028 [details] [review]
Use g_mapped_file_unref
Comment 11 Sebastian Dröge (slomo) 2009-12-04 13:49:46 UTC
commit a4193a326729bfb78772fd46557c93f41ef9387d
Author: Javier Jardón <jjardon@gnome.org>
Date:   Thu Dec 3 19:48:11 2009 +0100

    registry: Substitute deprecated GLib symbol: g_mapped_file_free
    
    Use g_mapped_file_unref if Glib >= 2.22 is available
    
    Fixes bug #560442.
Comment 12 Luis Menina 2009-12-21 02:11:09 UTC
*** Bug 605100 has been marked as a duplicate of this bug. ***