isuruf
commented
2 years ago Please see https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#customizing-the-compilers about customizing compilers.
Open manopapad opened 2 years ago
isuruf
commented
2 years ago Please see https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#customizing-the-compilers about customizing compilers.
isuruf
commented
2 years ago IIUC, the reason for setting these flags outside of conda-build is to improve the chances that a codebase built with these compilers will be ABI-compatible with the pre-built packages in the same conda environment (that were built with similar flags).
That's not the only goal. The other goal is to provide compilers outside of conda-build that behave mostly like the compilers in a conda-build setting.
timsnyder
commented
2 years ago @manopapad , you might also find https://conda-forge.org/docs/user/faq.html#faq-compiler-required-options useful. It is possible to use the conda-forge toolchain in an environment without using the activation scripts.
baszalmstra
commented
2 years ago There is also the DEBUG_CXXFLAGS env variable which you can use for debug builds I believe. But that does still contain -Og which also often doesn't given the desired debugging results.
baszalmstra
commented
2 years ago I currently have this in the root of my CMakeLists.txt.
# In a Conda environment the compiler activation scripts by default specify optimization flags. Even in
# debug mode. These flags make proper debugging very hard. To combat this issue, the code below removes the
# optimization flags (specified with `-Ox`) from the C(XX)_FLAGS if the build type is Debug. The compiler
# will then default to -O0, which should allow for proper debugging.
# This assumes that a multi-config generator is not used.
if (CMAKE_COMPILER_IS_GNUCXX AND CMAKE_BUILD_TYPE STREQUAL "Debug")
# Remove the -Ox flag from the compiler flags
string(REGEX REPLACE "-O[g0-9][ ]*" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
string(REGEX REPLACE "-O[g0-9][ ]*" "" CMAKE_C_FLAGS ${CMAKE_C_FLAGS})
endif()
m3vaz
commented
1 year ago The FAQ doesn't seem to discuss running the toolchain without the activation scripts, perhaps the link was meant to go to a specific revision?
Instead of creating an entirely separate compiler package, would it be possible to have an override environment variable for the optimization flags? (e.g. something like CONDA_OVERRIDE_CUDA)
timsnyder
commented
1 year ago The FAQ doesn't seem to discuss running the toolchain without the activation scripts, perhaps the link was meant to go to a specific revision?
You're right. I saw gcc mentioned in https://conda-forge.org/docs/user/faq.html#faq-compiler-required-options and didn't read it carefully enough. If you don't want the activation scripts, install (gcc, gxx and binutils). Those will give you all of the short-named symlinks.
If you don't want to have to specify $CONDA_PREFIX/include and $CONDA_PREFIX/lib via command-line arguments, you might also want the conda-gcc-specs package.
If I get a chance, I'll improve the FAQ entry.
feltech
commented
4 months ago Just to add my +1 to this.
I'd also like to see all the other superfluous/opinionated compiler switches removed. I'd rather manage them myself (e.g. via cmake/conan). Though the forced optimisation flag is the most frustrating.
I take the point that consistency between conda-build/packages and user environments is a goal. Perhaps forking+customising is the only reasonable solution?
Solution to issue cannot be found in the documentation.
Issue
We are using the conda-forge GNU compiler toolchain for building our packages. We would like to transition to also using the conda-forge GNU compilers for development and debugging. Unfortunately, it looks like when we activate an environment containing the GNU compilers, the activation scripts add the
-O2optimization flag to[C/CXX/F]FLAGS, which ends up being picked up by themaketoolchain, and thus removes debug info automatically from our builds:If we wanted to use the compilers, we would have to externally remove this flag from
[C/CXX/F]FLAGSafter conda activation has completed.The relevant snippet from the activation script:
comes from the following lines in the feedstock:
https://github.com/conda-forge/ctng-compiler-activation-feedstock/blob/main/recipe/activate-g%2B%2B.sh#L85-L93
IIUC, the reason for setting these flags outside of conda-build is to improve the chances that a codebase built with these compilers will be ABI-compatible with the pre-built packages in the same conda environment (that were built with similar flags).
I don't believe optimization flags are relevant for this goal. Please correct me if I'm wrong, but I don't think the level of optimization used when compiling a new binary affects whether it is ABI-compatible with a set of existing libraries. Therefore, assuming that the use of the conda-forge compilers outside of conda-build is an expected use case, I think you should not force a level of optimization on users.
I assume a potential fix for this would be to remove
-O2from@CXXFLAGS@and instead add it explicitly on this line: https://github.com/conda-forge/ctng-compiler-activation-feedstock/blob/main/recipe/activate-g%2B%2B.sh#L88 (and similarly for other flags).I would note that optimization flags are the most immediately problematic, but the same argument as above could be made for other flags that are set even outside of conda-build, but don't seem relevant to guaranteeing ABI compatibility, e.g.
-fmessage-length=0.Installed packages
Environment info