Closed MementoRC closed 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
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?
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?
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
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: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