Subject: pkg/21040: libintl management in packages
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/06/2003 18:37:39
>Synopsis: libintl management in packages
>Arrival-Date: Sun Apr 06 09:38:00 PDT 2003
>Originator: Quentin Garnier
>Release: NetBSD 1.6Q
Quentin Garnier - email@example.com
"Feels like I'm fiddling while Rome is burning down.
Should I lay my fiddle down and take a rifle from the ground ?"
Leigh Nash/Sixpence None The Richer, Paralyzed, Divine Discontents, 2002.
System: NetBSD padme 1.6Q NetBSD 1.6Q (NVIDIA_ACPI-$Revision: 1.3 $) #31: Thu Mar 20 13:54:34 CET 2003 cube@padme:/home/cube/src/nv-netbsd/netvidia/src/sys/arch/i386/compile/NVIDIA_ACPI i386
libintl.so must be managed with care by packages, since it can
easily lead to conflicts between the one in the base and the
one potentially installed by packages.
I'll take the example of GTK+ 2 and GLib 2: GLib 2 depends on
libintl.so, but doesn't need the new functionnalities (UTF8) of
gettext-lib-0.11.x, and therefore is satisfied with the one
provided by the base system.
On the other hand, GTK+ 2 can make use of those new
functionnalities, and this is actually required to make GTK+ 2
and Pango display strings from locale files written in
ISO-8859-1, since they must be converted to UTF8. When locale
files are written in UTF8, the problem doesn't show and
strings appear to be displayed correctly (this is the case for
news/gtk2-pan). But when locale files are written in
ISO-8859-1, they are not converted and therefore are truncated
at accentuated letters (UTF8 uses two bytes to encode them).
Adding a dependency on a newer libintl.so for GTK+ 2 isn't a
fix to that issue: libraries (and subsequent binaries that
depend on GTK+ 2) will be linked against both libintl.so from
base and from packages. The symbols from the base's libintl.so
are likely to supersede the ones from the packages libintl.so,
and the locales won't be converted to UTF8, nor displayed
Apart from that, one should take care of the order of the
inclusion of gettext-lib's buildlink2.mk, since one dependency
may define GNU_GETTEXT to link against packages' libintl.so.
This only concerns a chain of dependencies such as glib2/pango/
atk/gtk+2, and does not prevent a conflict between two unrelated
dependencies of package.
o Upgrade base's gettext to 0.11.x. We probably don't want that
(it would also require the import of libiconv). But this will
certainly solve the problem.
o Make symbols from base library weak, so they are superseded
by the ones from the packages library when an object is linked
o Carefully audit libintl usage by packages and fix mismanaged
chains of dependencies. This is not a complete fix though.
o This issue is quite like the pthreads one. A similar framework
could be used, but again, this would only clarify writing
Makefiles for packages, and would not prevent the problem. And
indeed, it is hard to mix several pthreads libraries.
o Maybe there are other nicer solutions, but that is all I could
Here is how I "fixed" the GLib/GTK+2 chain: making glib2 depends
on GNU gettext, and making sure GTK+2 doesn't include gettext-lib
buildlink2.mk too early.
RCS file: /cvsroot/pkgsrc/devel/glib2/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- devel/glib2/Makefile 2003/02/15 10:12:33 1.20
+++ devel/glib2/Makefile 2003/04/06 16:32:35
@@ -17,6 +17,7 @@
RCS file: /cvsroot/pkgsrc/devel/glib2/buildlink2.mk,v
retrieving revision 1.8
diff -u -r1.8 buildlink2.mk
--- devel/glib2/buildlink2.mk 2002/12/24 03:36:58 1.8
+++ devel/glib2/buildlink2.mk 2003/04/06 16:32:35
@@ -17,6 +17,8 @@
RCS file: /cvsroot/pkgsrc/x11/gtk2/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- x11/gtk2/Makefile 2003/02/15 11:02:29 1.23
+++ x11/gtk2/Makefile 2003/04/06 16:32:35
@@ -49,7 +49,7 @@
RCS file: /cvsroot/pkgsrc/x11/gtk2/buildlink2.mk,v
retrieving revision 1.6
diff -u -r1.6 buildlink2.mk
--- x11/gtk2/buildlink2.mk 2003/01/11 18:23:46 1.6
+++ x11/gtk2/buildlink2.mk 2003/04/06 16:32:35
@@ -20,7 +20,7 @@