GNOME Bugzilla – Bug 471123
move deprecated code to a separate section
Last modified: 2018-05-24 11:05:25 UTC
glib defines G_GNUC_DEPRECATED in macros.h, but is not using it. I know that it uses G_DISABLE_DEPRECATED in the header. Using G_GNUC_DEPRECATED deprecated on the actual symbols would have the following benefits: Clear error message (no need to wonder why a symbol has no prototype) macros.c:23: warning: 'do_no_use_me1' is deprecated (declared at macros.c:13) Possible memory saving and performance improvment. For a test I changed the macro to: #define G_GNUC_DEPRECATED \ __attribute__((deprecated, section (".text_deprecated"))) This causes all the deprecated symbols to be bundled in a separate section. When a library is used its not loaded into memory fully. Pages are loaded on demand. Thus if no application uses the deprecated stuff it not using memory. This also helps to improve the locality of the non-deprecated stuff. A quick search on some libs about how many deprecated symbols they have: glib : 62 gobject : 4 gdk : 104 gtk+ : 632 pango: 46 (be aware that some symbols are macros). Two question: * okay to change the define of G_GNUC_DEPRECATED * okay to make use of G_GNUC_DEPRECATED in glib/gtk+ (should ask pango/cairo/... guys too)
Note that most of pango's deprecated stuff comes from pangox which is a separate library.
The deprecation mechanism used in the gtk stack predates G_GNUC_DEPRECATED, and changing it now would be a lot of work. As you point out, it has some additional benefit, though.
I don't think this will actually move all the interesting code to .text_deprecated (also, .text.deprecated is a more common name). Only the public functions get this marking, none of the static function implementing the code. A better way to do a deprecation section would probably be to compile the deprecated source files with "-mtext=.text.deprecated".
lets retitle this bug to clarify what this is about
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/102.