When using Guix on top of GNU/Linux distribution other than GuixSD—a so-called foreign distro—a few additional steps are needed to get everything in place. Here are some of them.
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 package -i 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
110 MiB. Alternatively, the
glibc-utf8-locales is smaller but
limited to a few UTF-8 locales.
GUIX_LOCPATH variable plays a role similar to
LOCPATH in The GNU C Library Reference
Manual). There are two important differences though:
GUIX_LOCPATHis honored only by the libc in Guix, and not by the libc provided by foreign distros. Thus, using
GUIX_LOCPATHallows you to make sure the programs of the foreign distro will not end up loading incompatible locale data.
X.Yis 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.
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
.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
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
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.
nscd on the system, among other advantages, eliminates
this binary incompatibility problem because those
files are loaded in the
nscd process, not in applications
The majority of graphical applications use Fontconfig to locate and
load fonts and perform X11-client-side rendering. The
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
To display text written in Chinese languages, Japanese, or Korean in
graphical applications, consider installing
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 package -i 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:
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 ~/.guix-profile/share/fonts/truetype
After that, you can run
to make sure your TrueType fonts are listed there.
After installing fonts you may have to refresh the font cache to use
them in applications. The same applies when applications installed via
Guix do not seem to find fonts. To force rebuilding of the font cache
fc-cache -f. The
fc-cache command is provided by 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.
When you install Emacs packages with Guix, the elisp files may be placed either in $HOME/.guix-profile/share/emacs/site-lisp/ or in sub-directories of $HOME/.guix-profile/share/emacs/site-lisp/guix.d/. The latter directory exists because potentially there may exist thousands of Emacs packages and storing all their files in a single directory may be not reliable (because of name conflicts). So we think using a separate directory for each package is a good idea. It is very similar to how the Emacs package system organizes the file structure (see Package Files in The GNU Emacs Manual).
By default, Emacs (installed with Guix) “knows” where these packages
are placed, so you do not need to perform any configuration. If, for
some reason, you want to avoid auto-loading Emacs packages installed
with Guix, you can do so by running Emacs with
option (see Init File in The GNU Emacs Manual).
Guix offers individual compiler packages such as
gcc but if you
are in need of a complete toolchain for compiling and linking source
code what you really want is the
gcc-toolchain package. This
package provides a complete GCC toolchain for C/C++ development,
including GCC itself, the GNU C Library (headers and binaries, plus
debugging symbols in the
debug output), Binutils, and a linker
The wrapper’s purpose is to inspect the
passed to the linker, add corresponding
-rpath arguments, and
invoke the actual linker with this new set of arguments. By default,
the linker wrapper refuses to link to libraries outside the store to
ensure “purity”. This can be annoying when using the toolchain to
link with local libraries. To allow references to libraries outside the
store you need to define the environment variable