conda-forge / ctng-compilers-feedstock

A conda-smithy repository for ctng-compilers.
BSD 3-Clause "New" or "Revised" License
12 stars 28 forks source link

CFLAGS activation #159

Closed MementoRC closed 3 weeks ago

MementoRC commented 3 weeks ago

Comment:

Hello, in a recipe I need to have both the linux-64 gcc (to build a tmp tool) and the linux-ppc64le gcc. The recipe has the ppc64le cross-compiler in build and I try to install the 64 gcc inside a local conda environment. When I retrieve CFLAGS from that environment, it seems to include the cross-compiler CFLAGS:

INFO: activate-gcc_linux-64.sh made the following environmental changes:
-build_alias=powerpc64le-conda-linux-gnu
+build_alias=x86_64-conda-linux-gnu
...
+CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/zig-0.13.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -mcpu=power8 -mtune=power8 -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/zig-0.13.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix
-CFLAGS=-mcpu=power8 -mtune=power8 -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/zig-0.13.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix

The new CFLAGS seems to be a concatenation of 64 CFLAGS and ppc64le CFLAGS I looked inside this recipe, but do not see where the activation/deactivation scripts reside

h-vetinari commented 3 weeks ago

I looked inside this recipe, but do not see where the activation/deactivation scripts reside

That would be in https://github.com/conda-forge/ctng-compiler-activation-feedstock

If you install gcc_linux-ppc64le into a build environment on a linux-64 agent, you'll necessarily also have a working compiler for linux-64. If you need to compile something for the build architecture, you can so something like:

if [[ "${CONDA_BUILD_CROSS_COMPILATION:-0}" == 1 ]]; then
  (  # open new scope so that variables don't get overwritten for main build
    CC=${CC_FOR_BUILD}
    CXX=${CXX_FOR_BUILD}
    # remove architecture flags (won't match build architecture)
    CFLAGS="$(echo ${CFLAGS} | sed 's/ -march=[^ ]*//g' | sed 's/ -mcpu=[^ ]*//g' | sed 's/ -mtune=[^ ]*//g')"
    CXXFLAGS="$(echo ${CXXFLAGS} | sed 's/ -march=[^ ]*//g' | sed 's/ -mcpu=[^ ]*//g' | sed 's/ -mtune=[^ ]*//g')"
    # point to correct prefix
    CFLAGS=${CFLAGS//$PREFIX/$BUILD_PREFIX}
    CXXFLAGS=${CXXFLAGS//$PREFIX/$BUILD_PREFIX}
    LDFLAGS=${LDFLAGS//$PREFIX/$BUILD_PREFIX}
    # compile something for build-arch here
  )
fi
MementoRC commented 3 weeks ago

That's what I was doing but then I have to install a bunch of libs/tools and wanted to have a cleaner build: so I did this:

  mamba create -n qemu-execve -y -c conda-forge \
    gcc_linux-64 \
    sysroot_linux-64=2.28 \
    ...

      local CC=$(mamba run -n qemu-execve which x86_64-conda-linux-gnu-gcc | grep -Eo '/.*gcc' | tail -n 1)
      mamba run -n qemu-execve bash -c 'echo "${CFLAGS:-}" > _cflags.txt' >& /dev/null
      local CFLAGS=$(< _cflags.txt)
      CFLAGS=${CFLAGS//-mcpu=power8 -mtune=power8/}

So I thought that there would not be any 'leakage' between environments, but I had to add the last CFLAGS line. In qemu-execve there should be no ppc64le related information (I do have the ppc64le resource in the build environment). The build works fine, it's just that I thought this was a bug - I do see that the activation scripts are doing their job of deactivating and activating, it's just that for CFLAGS they seem not to work correctly

Am I missing something?

h-vetinari commented 3 weeks ago

but then I have to install a bunch of libs/tools and wanted to have a cleaner build:

what does that mean? why should libs/tools care about what other things are in the build environment, much less fail based on that?

MementoRC commented 3 weeks ago

I felt it would be cleaner to have a build: section that only had packages required for the specific recipe (in this case zig), and that the packages needed to build intermediate tools would be better organized within the build script under a dedicated environment. Within that dedicated environment, I was surprised to see that the environment variables had definitions from the build environment, even though the activation/deactivation scripts seemed to indicate that old variables were removed and new variables where set as in:

-CFLAGS= -mtune=power8 ....  # ppc64le build environment
+CFLAGS= -march=nocona -mtune=haswell ... # x86_64 dedicated environment

But this discussion probably stems from my ignorance and you seem to confirm that it is the case. I have a solution for the recipe in question, so we can close this issue Thank you