1

I'm working with RHEL6 systems, but need to port the code using C++11 (and even C++14) features. This forced me to build gcc-8.2 by hand, installed under a private prefix (/prod/pfe/local). This created a number of executables under /prod/pfe/local/bin: gcc, g++, ld, and gfortran.

I'm now trying to build CBLAS, which uses the above gfortran. Building the library (cblas_LINUX.a) works fine, but creating an executable fails with a cryptic errors cited in the title:

gfortran -o xscblat1 c_sblat1.o c_sblas1.o ../lib/cblas_LINUX.a
/prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: _edata: invalid version 21 (max 4) /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld: /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so: error adding symbols: bad value

Did I configure build gfortran incorrectly? If not, how do I solve this problem -- additional FFLAGS or LDFLAGS of some kind?

Mikhail T.
  • 3,043
  • 3
  • 29
  • 46
  • Can you provide the result of `which gcc g++ gfortran ld` and of `echo $PATH`? – Pierre de Buyl Sep 18 '18 at 07:45
  • The message implies that your application links at run time to the wrong version of libgfortran. gfortran -v, ldd and g++ -print-search-dirs also should give clues. Besides, it seems your version of gfortran should be linking to libgfortran4, and may not do so if this antique libgfortran is searched first. – tim18 Sep 18 '18 at 12:11

1 Answers1

3

Ok, according to the gcc-developers, this is a known bug triggered by the use of the new linker (gold).

Rebuilding the compiler suit with --disable-gold solves the problem.

Update: correction -- somehow, disabling gold is not good enough. Going back to the binutils-2.30 is what I ended up doing...

Mikhail T.
  • 3,043
  • 3
  • 29
  • 46