all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: nix-dev@lists.science.uu.nl, gcc@gcc.gnu.org,
	cfe-dev@lists.llvm.org, Shea Levy <shea@shealevy.com>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment
Date: Tue, 18 Oct 2016 11:25:57 +0200	[thread overview]
Message-ID: <87vawqm2je.fsf@gnu.org> (raw)
In-Reply-To: <87r37gp8dt.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me> (Shea Levy via cfe-dev's message of "Sun, 16 Oct 2016 12:26:54 -0400")

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’.
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

       reply	other threads:[~2016-10-18  9:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r37gp8dt.fsf@shlevy-laptop.i-did-not-set--mail-host-address--so-tickle-me>
2016-10-18  9:25 ` Ludovic Courtès [this message]
     [not found]   ` <87vawqm2je.fsf-mXXj517/zsQ@public.gmane.org>
2016-10-18 11:03     ` [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment Shea Levy via cfe-dev
2016-10-18 11:19   ` Shea Levy
2016-10-18 12:59     ` Ludovic Courtès
     [not found]       ` <8737jtlsnw.fsf-mXXj517/zsQ@public.gmane.org>
2016-10-18 13:46         ` Nathan Froyd via cfe-dev
     [not found]           ` <CAGepuV+VpTJfu=RUtEioxx47QgKDCvkeN40wisGt9aceXj1mDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-27 17:11             ` Will Dietz via cfe-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vawqm2je.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=cfe-dev@lists.llvm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=nix-dev@lists.science.uu.nl \
    --cc=shea@shealevy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.