This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment
- From: ludo at gnu dot org (Ludovic Courtès)
- To: nix-dev at lists dot science dot uu dot nl, <gcc at gcc dot gnu dot org>, cfe-dev at lists dot llvm dot org, Shea Levy <shea at shealevy dot com>
- Cc: Guix-devel <guix-devel at gnu dot org>
- Date: Tue, 18 Oct 2016 11:25:57 +0200
- Subject: Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment
- Authentication-results: sourceware.org; auth=none
- References: <87r37gp8dt.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me>
Hi Shea,
Shea Levy skribis:
> Unlike the traditional approach of installing system libraries into one
> central location like /usr/{lib,include}, the nix package manager [1]
> installs each package into it's own prefix
> (e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,
> each package is built in its own environment determined from its
> explicitly listed dependencies, regardless of what else is installed on
> the system. Because not all package build scripts properly respect
> CFLAGS etc., we currently wrap the compiler [2] to respect custom
> environment variables like NIX_CFLAGS_COMPILE, so during the build of a
> package that depends on zlib and Xlib might have NIX_CFLAGS_COMPILE set
> to "-isystem /nix/store/bl0rz2xinsm9yslghd7n5vaba86zxknh-libX11-1.6.3-dev/include -isystem /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include".
>
> Unfortunately, as you can see if you click through the link or look
> through the git history, the wrapper is quite complex (frankly, hacky)
> [2]: https://github.com/NixOS/nixpkgs/blob/8cbdd9d0c290e294a9d783c8868e738db05c9ce2/pkgs/build-support/cc-wrapper/cc-wrapper.sh
Guix avoids the compiler wrapper altogether like this:
• We use C_INCLUDE_PATH, LIBRARY_PATH, and friends:
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gcc.scm#n296>.
• We have a simple linker wrapper aimed at adding -Wl,-rpath flags:
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ld-wrapper.in#n42>.
The comment in that file explains why the other options considered
were unsuitable.
• We modify the built-in “lib” spec of GCC to add the necessary -L and
-rpath flags:
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gcc.scm#n218>.
• Likewise, we tell Clang where to find libc and friends:
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/clang-libc-search-path.patch>
<http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/llvm.scm#n161>.
This is not too intrusive and more robust than wrapping everything.
I suppose GCC and Clang could facilitate this by providing configure
options to augment the “lib” spec, specify the location of libc alone,
or something along these lines.
Thoughts?
Ludo’.