ANTsRCore/configure not detecting the correct toolchain

[SlicerMorph]

On Centos 7.2 base compiler toolkit is too old (4.8.5.) We use modules functionality to activate gcc/9.3.0 and R/4.1.1. When I git clone ITKR and ANTsRCore to build the package from source, I can see that the ./configure in ITKR detects the correct build environment provided by the modules functionality, but not the ANTsRCore. As a consequence of not using the identical toolchain, ANTsRCore build, but fails to install with incorrect Symbol error. See truncated output from the same command line session:

How can I fix this?

[maga@magalab-head ITKR]$ module list
Currently Loaded Modulefiles:
  1) sge/2011.11p1   2) gcc/9.3.0       3) R/4.1.1
[maga@magalab-head ITKR]$ which gcc
/cm/shared/apps/gcc/9.3.0/bin/gcc
[maga@magalab-head ITKR]$ which R
/cm/shared/apps/R/4.1.1/bin/R
[maga@magalab-head ITKR]$ echo $LD_LIBRARY_PATH
/cm/shared/apps/R/4.1.1/lib64:/cm/shared/apps/gcc/9.3.0//lib:/cm/shared/apps/gcc/9.3.0//lib64:/cm/shared/apps/sge/2011.11p1/lib/linux-x64

[maga@magalab-head ITKR]$ ./configure
Cloning into 'itks'...
remote: Enumerating objects: 496271, done.
remote: Counting objects: 100% (4489/4489), done.
remote: Compressing objects: 100% (2032/2032), done.
remote: Total 496271 (delta 2588), reused 4076 (delta 2445), pack-reused 491782
Receiving objects: 100% (496271/496271), 170.39 MiB | 25.35 MiB/s, done.
Resolving deltas: 100% (392428/392428), done.
Already on 'master'
Checking out files: 100% (5381/5381), done.
Note: checking out 'e21a56d1227c5433066237060368cb4532b8a9d2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at e21a56d... Merge branch 'release'
**-- The CXX compiler identification is GNU 9.3.0
-- The C compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /cm/shared/apps/gcc/9.3.0/bin/c++
-- Check for working CXX compiler: /cm/shared/apps/gcc/9.3.0/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /cm/shared/apps/gcc/9.3.0/bin/gcc
-- Check for working C compiler: /cm/shared/apps/gcc/9.3.0/bin/gcc -- works**
-- Detecting C compiler ABI info
^C

[maga@magalab-head ANTsRCore]$ ./configure
linux-gnu 0
Cloning into 'ants'...
remote: Enumerating objects: 25097, done.
remote: Counting objects: 100% (530/530), done.
remote: Compressing objects: 100% (409/409), done.
remote: Total 25097 (delta 230), reused 297 (delta 116), pack-reused 24567
Receiving objects: 100% (25097/25097), 21.31 MiB | 21.64 MiB/s, done.
Resolving deltas: 100% (17746/17746), done.
Already on 'master'
Already up-to-date.
Note: checking out '2251ca1dfca9d27a58623eb36784704a032d97a0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 2251ca1... Merge pull request #1115 from ANTsX/KKDefaults
**-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features**
^C

[stnava]

I've seen this type of thing before - try reading

https://stackoverflow.com/questions/1616983/building-r-packages-using-alternate-gcc

I'm not sure what the R-correct thing is to do here but making sure that R and global (or really cmake) evironment definitions of CC, CXX etc are consistent. this might be achievable through global environment variables but you may also need to check other places.

here is an example of a file I used at some point long ago:

cat ~/.R/Makevars
CXX = /usr/local/Cellar/gcc/9.1.0/bin/g++-9
CXXSTD = -std=c++11
CXXFLAGS = -fsanitize=undefined,address -fno-omit-frame-pointer

CXX98 = /usr/local/Cellar/gcc/9.1.0/bin/g++-9
CXX98STD = -std=c++98

CXX11 = /usr/local/Cellar/gcc/9.1.0/bin/g++-9
CXX11STD = -std=c++11

CXX14 = /usr/local/Cellar/gcc/9.1.0/bin/g++-9
CXX14STD = -std=c++14

[SlicerMorph]

I will try those when I am at work, but I will counter the argument this happening at the ./configure (bash level), not in R. (I am simply running those ./configure scripts locally in bash to see the output). Are those scripts searching for the CC/GCC variables differently between ITKR and ANTsRCore then? Because those outputs are from the same bash session ITKR/configure detects the correct toolchain but not ANTsRCore/configure

[stnava]

maybe - let us know what you find out.

[stnava]

• both the R variables and the environment variables should match

so cmake and R are consistent .... your system - by definition of the issue - is defining these differently.

[muratmaga]

* both the R variables and the environment variables should match

so cmake and R are consistent .... your system - by definition of the issue - is defining these differently.

There was no explicit CC variable declared in the bash environment. export CC=/cm/shared/apps/gcc/9.3.0/bin/gcc made the ANTsRCore./configure script detect that, and I am now running the R CMD INSTALL to see if still encounter the undefined symbol error (which I suspect I wont).

However, all I can say that lack of CC variable was not an issue for ITKR in finding the correct toolchain. So it might be worthwhile to make them similar.

[stnava]

I think that's an issue on your end. we can't know ahead of time what CC variables you want. maybe someone else has an idea of what to do but otherwise this is a fix on your end kind of issue.