linking against -lintl

Kevin Day thekevinday at gmail.com
Sat Sep 2 18:41:42 PDT 2006


I have always felt it rather insecure or at the very least risky to
force all packages to link to -lintl, when all of them do not.

I have for some time successfully compiled a complete NLS/libintl free
system and have moved back and forth to compare performance and bugs.
During all of this I made notes on what did and did not like external
libintl.

Out of a list of 639 programs that I successfully compiled under my
HLFS based system, the following programs where the only ones with
apparent problems:
  Linux-PAM
  shadow
  psmisc
  ms-sys
  alsa-utils
  aspell
  gftp
  linux (the kernel)
  tvtime
  php
  lbreakout2
  wesnoth

That's it! I have not tested yet, whether or not the other 600+
programs did not disable NLS with an external libintl.  However, in
order to disable nls entirely I had to hack/modify/patch at least ~30
projects.  I also passed --enable-nls to every applicable project.

All of the mentioned projects above could be fixed by simply
executing: " make LDFLAGS='-lintl' ", except for the following:

gftp, which failed because it re-defined gettext AFTER including the
appropriate nls/gettext headers!  My fix was: sed -i -e '/#define
gettext(str) (str)/d' src/gtk/misc-gtk.c

the linux kernel, which only uses nls for it's scripts.  The hack was
a patch I called skip_nls:
--- linux-2.6.17.4/scripts/kconfig/Makefile.orig        2006-07-24
11:10:39.000000000 -0500
+++ linux-2.6.17.4/scripts/kconfig/Makefile     2006-07-24
11:12:16.000000000 -0500
@@ -122,9 +122,7 @@
      if echo "\#include <libintl.h>" | $(HOSTCC) $(HOSTCFLAGS) -E - >
/dev/null 2>&1 ; \
      then echo yes ; \
      else echo no ; fi)
-ifeq ($(KBUILD_HAVE_NLS),no)
  HOSTCFLAGS     += -DKBUILD_NO_NLS
-endif

 # generated files seem to need this to find local include files
  HOSTCFLAGS_lex.zconf.o := -I$(src)


Any thoughts on this?
--
Kevin Day



More information about the hlfs-dev mailing list