GNU bug report logs - #72669
gcc-toolchain environment variables

Previous Next

To reply to this bug, email your comments to 72669 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: creightor <creightor <at> disroot.org>
To: bug-guix <at> gnu.org
Subject: gcc-toolchain environment variables
Date: Fri, 16 Aug 2024 12:02:35 +0300

Hi, it looks like having the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH 
environment variables set by the gcc-toolchain package in a profile can 
cause issues.

For example, I have gcc-toolchain installed, compiled a cross-binutils 
for aarch64-elf and then tried to compile a gcc cross-compiler for the 
same target using those binutils.

These are the flags I used for binutils:

--target=aarch64-none-elf --disable-multilib

and for the gcc cross-compiler:

--target=aarch64-none-elf --disable-multilib --disable-bootstrap 
--enable-languages=c,c++ --without-headers --with-newlib 
--disable-hosted-libstdcxx --disable-libssp --disable-libsanitizer

From what I understand, there should be no headers available when 
creating a cross-compiler for a freestanding platform like this.

Since these include paths were added with C_INCLUDE_PATH and 
CPLUS_INCLUDE_PATH, something like `#if __has_include(<sys/auxv.h>)` in 
gcc's libgcc/config/aarch64/cpuinfo.c evaluated to true and the rest of 
the build would fail.

Unsetting them didn't work since apparently gcc-toolchain relies on them 
set so I had these two variables unset in BASE_TARGET_EXPORTS in gcc's 
root Makefile.in which should only apply to the newly built gcc 
cross-compiler and so the build finished fine.

Message #8 received at 72669 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Schwinge <tschwinge <at> baylibre.com>
To: creightor <at> disroot.org, 72669 <at> debbugs.gnu.org
Subject: Re: bug#72669: gcc-toolchain environment variables
Date: Thu, 07 Nov 2024 10:20:40 +0100

Indeed this is a problem, when attempting to build GCC in a Guix profile
with 'gcc-toolchain' installed.  What you may do is create wrapper
binaries so that the Guix GCC's 'etc/profile' is only active if using the
Guix GCC (that is, when building your cross-GCC's compilers), but isn't
active (and therefore 'C_INCLUDE_PATH', 'CPLUS_INCLUDE_PATH',
'LIBRARY_PATH' etc. not defined) when your cross-GCC builds its target
libraries.  This means, you have to invoke the Guix GCC from outside of
the Guix profile.  Something like this:

    $ guix install -p "$GUIX_GCC" gcc-toolchain

..., and then script something like:

    rm -rf "$GUIX_GCC"_bin
    mkdir "$GUIX_GCC"_bin
    for f in "$GUIX_GCC"/bin/* "$GUIX_GCC"/sbin/*; do
      f_=$(basename "$f")
      case "$f" in
        */c++ \
        | */g++ \
        | */gcc \
        | */*-c++ \
        | */*-g++ \
        | */*-gcc )
          cat > "$GUIX_GCC"_bin/"$f_" <<EOF
    #!/bin/sh
    
    set -e
    
    d=\$(dirname "\$0")
    
    . "\$d"/../$GUIX_GCC/etc/profile
    
    "\$d"/../$f "\$@"
    EOF   
          chmod +x "$GUIX_GCC"_bin/"$f_"
          ;;
        *)
          ln -s ../"$f" "$GUIX_GCC"_bin/"$f_"
          ;;
      esac
    done

..., and instead of '"$GUIX_GCC"/bin/gcc' etc. then use
'"$GUIX_GCC"_bin/gcc' etc.


In my opinion, the Guix-profile-wide setting of these environment
variables (via Guix GCC's 'etc/profile') doesn't feel quite right -- but
I'm still new to Guix, so...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.