6

I am trying to compile some code within a Conda environment, where I previously installed the compiler package gcc_linux-64.

However, even after deactivating and reactivating again the environment, gcc is still /usr/bin/gcc.

What should I do to have Conda working as expected, ie. using the tool I install ? Like it is for other software like git or whatever.

Any help would be appreciated, thanks in advance !

mguijarr
  • 7,641
  • 6
  • 45
  • 72
  • 1
    I believe the executable is called `gcc-conda` or something similar. See: https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html#using-the-compiler-packages – darthbith Oct 28 '18 at 13:46
  • 1
    Ok, but the makefiles etc use 'gcc' not 'gcc-conda'... What is the point of installing gcc with Conda if it does not replace the system gcc? When installing git for example it is not called 'git-conda' – mguijarr Oct 30 '18 at 12:44
  • You can usually control the value of variables in a Makefile with an environment variable. I'm not sure why they made this decision, but probably because the compiler is much more fundamental to the system operation and replacing it (even by putting it first in the path) is more likely to cause linking problems, etc. than other programs (such as git). – darthbith Oct 30 '18 at 12:53
  • 1
    Thanks for the comments @darthbith... It seems strange to me, though. Sometimes I think I would better use nix instead of Conda – mguijarr Oct 30 '18 at 12:54
  • What do you mean use nix instead of Conda? They are completely separate... *nix implies an operating system, while Conda is simply a package manager (that works on any platform)... – darthbith Oct 30 '18 at 12:55
  • nix is the name of the Nix package manager, it can replace Conda and I really think it is better – mguijarr Oct 30 '18 at 17:27
  • Ah, thanks for clarifying! I will have to investigate – darthbith Oct 30 '18 at 19:27
  • You should create links to replace the system-wide packages, alias also works, though. https://stackoverflow.com/questions/59284298/conda-install-c-anaconda-gcc-linux-64-not-being-used – Jay Apr 03 '20 at 14:44

2 Answers2

5

If you do:

export CONDA_BUILD=1
conda activate <name-of-env-in-which-gcc_linux-64-is-installed>

You will see:

INFO: activate-binutils_linux-64.sh made the following environmental changes:
+ADDR2LINE=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-addr2line
+AR=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ar
+AS=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-as
+CXXFILT=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-c++filt
+ELFEDIT=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-elfedit
+GPROF=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gprof
+LD=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ld
+LD_GOLD=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ld.gold
+NM=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-nm
+OBJCOPY=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-objcopy
+OBJDUMP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-objdump
+RANLIB=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ranlib
+READELF=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-readelf
+SIZE=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-size
+STRINGS=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-strings
+STRIP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-strip
INFO: activate-gcc_linux-64.sh made the following environmental changes:
+CC=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cc
+CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+CPP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cpp
+CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2
+DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og
+GCC=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc
+GCC_AR=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-ar
+GCC_NM=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-nm
+GCC_RANLIB=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib
+LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,-rpath,/lib -L/lib
+_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_conda_cos6_linux_gnu

In your make file, you could use variables like $CC instead.

Nehal J Wani
  • 16,071
  • 3
  • 64
  • 89
  • I have the same result without exporting `CONDA_BUILD` ; still, `gcc` is system gcc. I didn't write the makefile, I would prefer not to modify it. – mguijarr Nov 06 '18 at 06:37
  • Yes, gcc will always remain system gcc. You need to use $CC instead. I just exported the CONDA_BUILD variable to show the verbose output on activating the environment. – Nehal J Wani Nov 06 '18 at 10:27
  • 9
    I'm having the same problem as the OP. I do not think changing the makefiles is supposed to be necessary. I think `gcc` should be changed. From https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html: "Instead of gcc, the executable name of the compiler you use will be something like x86_64-conda_cos6-linux-gnu-gcc [...]. Many build tools such as make and CMake search by default for a compiler named simply gcc, so we set environment variables to point these tools to the correct compiler. [...] Conda-build does this activation for you". Except it doesn't. – sigvaldm May 12 '19 at 15:42
  • @sigvaldm Not sure if you've sorted this out - I just ran into the same problem. To compile my c scripts in a conda env, I've found that using the environment-defined env variable to call the environment's gcc compiler works: `$GCC -o program program.c`. I'm a total rookie with C, just learning hello world in fact; so the make tool is out of my scope atm; that being said, if you're looking to just compile with the env compiler not the system, the env variable, while perhaps unintuitive, works well. – skytwosea May 24 '20 at 00:55
  • Thank you, @skytwosea. Yes I already sorted it out, though I no longer remember how. Once you get many files and arguments, you may want to take a look at makefiles (CMake is the next step). It will execute the right commands for you. When you download 3rd party software you don't want to change their files, and so going into their makefile and typing $(GCC) isn't a good option. Often such files use a variable $(CC) instead of gcc, so you can set that. I don't remember if my example didn't do that, or if Anaconda didn't set $(CC) at the time. Anyway, welcome to the C world :) – sigvaldm May 26 '20 at 06:59
2

The issue is the name of the gcc compiler that conda installs. Because it isn't just gcc, it's some long complicated thing, eg. x86_64-conda_cos6-linux-gnu-gcc, it won't override the system executable, even if your conda directory is earlier in your PATH variable.

The solution is to softlink your conda gcc compiler into your local binary directory, eg. ln -s path/to/conda/gcc ~/.local/bin/gcc, and then put that ahead of your system binary directory in your PATH variable, eg. export PATH=$HOME/.local/bin:$PATH where your shell is sourced, ie. ~/.bashrc, ~/.bash_profile, ~/.zshrc, etc.

This will then point to your conda executable before the system one, and should have the appropriate name to override it.

Keep in mind that if you delete your environment, or replace / update the gcc installed in it, you will need to update the softlink accordingly. Unless you need lots of different gcc versions, I'd just install it to your base env, do the soft link, and don't touch it after that. Hacky, but it works.