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 793252 - Optionally use libunistring or libicu to provide Unicode data
Optionally use libunistring or libicu to provide Unicode data
Product: glib
Classification: Platform
Component: i18n
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
Depends on:
Reported: 2018-02-07 12:57 UTC by Philip Withnall
Modified: 2018-05-24 20:11 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Philip Withnall 2018-02-07 12:57:05 UTC
GLib currently has around 1MB of Unicode tables loaded in memory for providing character information. That memory is shared between all processes, so the hit is not large, but for smaller devices it’s still a bit of a problem.

Given that libicu and libunistring are widely available on Linux, and loaded by gnome-shell, WebKit, flatpak helpers, gnome-builder, amongst others (see `sudo grep libunistring /proc/*/maps`), we could consider using one of them (if available) to provide character information.

On really small embedded devices, people seem to want to drop the Unicode data from GLib entirely. I don’t know if a platform-specific replacement is available (does uclibc have the right data?). I suspect dropping it entirely from GLib will break too many functions at runtime. We could look at making sure it’s optimised out by -fdata-sections -ffunction-sections -Wl,--gc-sections if unused.
Comment 1 GNOME Infrastructure Team 2018-05-24 20:11:14 UTC
-- 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: