2.4.1 Locales

Packages installed via Guix will not use the locale data of the host system. Instead, you must first install one of the locale packages available with Guix and then define the GUIX_LOCPATH environment variable:

$ guix install glibc-locales
$ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

Note that the glibc-locales package contains data for all the locales supported by the GNU libc and weighs in at around 930 MiB⁹. If you only need a few locales, you can define your custom locales package via the make-glibc-utf8-locales procedure from the (gnu packages base) module. The following example defines a package containing the various Canadian UTF-8 locales known to the GNU libc, that weighs around 14 MiB:

(use-modules (gnu packages base))

(define my-glibc-locales
  (make-glibc-utf8-locales
   glibc
   #:locales (list "en_CA" "fr_CA" "ik_CA" "iu_CA" "shs_CA")
   #:name "glibc-canadian-utf8-locales"))

The GUIX_LOCPATH variable plays a role similar to LOCPATH (see LOCPATH in The GNU C Library Reference Manual). There are two important differences though:

1. GUIX_LOCPATH is honored only by the libc in Guix, and not by the libc provided by foreign distros. Thus, using GUIX_LOCPATH allows you to make sure the programs of the foreign distro will not end up loading incompatible locale data.
2. libc suffixes each entry of GUIX_LOCPATH with /X.Y, where X.Y is the libc version—e.g., 2.22. This means that, should your Guix profile contain a mixture of programs linked against different libc version, each libc version will only try to load locale data in the right format.

This is important because the locale data format used by different libc versions may be incompatible.

2.4.2 Name Service Switch

When using Guix on a foreign distro, we strongly recommend that the system run the GNU C library’s name service cache daemon, nscd, which should be listening on the /var/run/nscd/socket socket. Failing to do that, applications installed with Guix may fail to look up host names or user accounts, or may even crash. The next paragraphs explain why.

The GNU C library implements a name service switch (NSS), which is an extensible mechanism for “name lookups” in general: host name resolution, user accounts, and more (see Name Service Switch in The GNU C Library Reference Manual).

Being extensible, the NSS supports plugins, which provide new name lookup implementations: for example, the nss-mdns plugin allow resolution of .local host names, the nis plugin allows user account lookup using the Network information service (NIS), and so on. These extra “lookup services” are configured system-wide in /etc/nsswitch.conf, and all the programs running on the system honor those settings (see NSS Configuration File in The GNU C Reference Manual).

When they perform a name lookup—for instance by calling the getaddrinfo function in C—applications first try to connect to the nscd; on success, nscd performs name lookups on their behalf. If the nscd is not running, then they perform the name lookup by themselves, by loading the name lookup services into their own address space and running it. These name lookup services—the libnss_*.so files—are dlopen’d, but they may come from the host system’s C library, rather than from the C library the application is linked against (the C library coming from Guix).

And this is where the problem is: if your application is linked against Guix’s C library (say, glibc 2.24) and tries to load NSS plugins from another C library (say, libnss_mdns.so for glibc 2.22), it will likely crash or have its name lookups fail unexpectedly.

Running nscd on the system, among other advantages, eliminates this binary incompatibility problem because those libnss_*.so files are loaded in the nscd process, not in applications themselves.

Note that nscd is no longer provided on some GNU/Linux distros, such as Arch Linux (as of Dec. 2024). nsncd can be used as a drop-in-replacement. See the nsncd repository and this blog post for more information.

2.4.3 X11 Fonts

The majority of graphical applications use Fontconfig to locate and load fonts and perform X11-client-side rendering. The fontconfig package in Guix looks for fonts in $HOME/.guix-profile by default. Thus, to allow graphical applications installed with Guix to display fonts, you have to install fonts with Guix as well. Essential font packages include font-ghostscript, font-dejavu, and font-gnu-freefont.

Once you have installed or removed fonts, or when you notice an application that does not find fonts, you may need to install Fontconfig and to force an update of its font cache by running:

guix install fontconfig
fc-cache -rv

To display text written in Chinese languages, Japanese, or Korean in graphical applications, consider installing font-adobe-source-han-sans or font-wqy-zenhei. The former has multiple outputs, one per language family (see Packages with Multiple Outputs). For instance, the following command installs fonts for Chinese languages:

guix install font-adobe-source-han-sans:cn

Older programs such as xterm do not use Fontconfig and instead rely on server-side font rendering. Such programs require to specify a full name of a font using XLFD (X Logical Font Description), like this:

-*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

To be able to use such full names for the TrueType fonts installed in your Guix profile, you need to extend the font path of the X server:

xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

After that, you can run xlsfonts (from xlsfonts package) to make sure your TrueType fonts are listed there.

2.4.4 X.509 Certificates

The nss-certs package provides X.509 certificates, which allow programs to authenticate Web servers accessed over HTTPS.

When using Guix on a foreign distro, you can install this package and define the relevant environment variables so that packages know where to look for certificates. See X.509 Certificates, for detailed information.

2.4.5 Emacs Packages

When you install Emacs packages with Guix, the Elisp files are placed under the share/emacs/site-lisp/ directory of the profile in which they are installed. The Elisp libraries are made available to Emacs through the EMACSLOADPATH environment variable, which is set when installing Emacs itself.

Additionally, autoload definitions are automatically evaluated at the initialization of Emacs, by the Guix-specific guix-emacs-autoload-packages procedure. This procedure can be interactively invoked to have newly installed Emacs packages discovered, without having to restart Emacs. If, for some reason, you want to avoid auto-loading the Emacs packages installed with Guix, you can do so by running Emacs with the --no-site-file option (see Init File in The GNU Emacs Manual).

Note: Most Emacs variants are now capable of doing native compilation. The approach taken by Guix Emacs however differs greatly from the approach taken upstream.

Upstream Emacs compiles packages just-in-time and typically places shared object files in a special folder within your user-emacs-directory. These shared objects within said folder are organized in a flat hierarchy, and their file names contain two hashes to verify the original file name and contents of the source code.

Guix Emacs on the other hand prefers to compile packages ahead-of-time. Shared objects retain much of the original file name and no hashes are added to verify the original file name or the contents of the file. Crucially, this allows Guix Emacs and packages built against it to be grafted (see grafts), but at the same time, Guix Emacs lacks the hash-based verification of source code baked into upstream Emacs. As this naming schema is trivial to exploit, we disable just-in-time compilation.

Further note, that emacs-minimal—the default Emacs for building packages—has been configured without native compilation. To natively compile your emacs packages ahead of time, use a transformation like --with-input=emacs-minimal=emacs.