Configuration with upstream Fortran LAPACK ignores F77 environmental variable

[marcfehling]

I am trying to compile libflame with clang/flang. I specify the compilers via environmental variables like this:

CC=mpicc F77=mpifort CFLAGS="-march=znver2 -O3 -DNDEBUG" \
./configure --enable-lapack2flame --enable-dynamic-build --disable-warnings --prefix=${BIN_DIR}/libflame-5.2.0

Compilation used to work just fine, but now I get the error that the command f77 was not found:

$ make
Generating monolithic include/x86_64-unknown-linux-gnu/FLAME.h......................................................................................................................................................................................................................................................................................................................
Generated monolithic include/x86_64-unknown-linux-gnu/FLAME.h
Generating monolithic include/x86_64-unknown-linux-gnu/blis1.h..................
Generated monolithic include/x86_64-unknown-linux-gnu/blis1.h
Generating monolithic include/x86_64-unknown-linux-gnu/FLA_f2c.h...
Generated monolithic include/x86_64-unknown-linux-gnu/FLA_f2c.h
Building src/map/common/lapacksrc/fortran/la_constants.f90
bash: f77: command not found
make: *** [Makefile:610: obj/x86_64-unknown-linux-gnu/src/la_constants.mod] Error 127

I ran a git bisect session and identified 74b56a2 (#89) as the first bad commit.

It seems like the F77 compiler specified via environmental variables is ignored when building the upstream versions of the LAPACK library. Can you confirm that?

In the meantime, adding the configuration option --enable-legacy-lapack works as a workaround.

[iotamudelta]

We're looking at it. Prior to #89 there was no Fortran in libflame - so F77 was not used.

[iotamudelta]

#106 hopefully addresses this issue.

[marcfehling]

Something is still not quite right. When I specify FC and FFLAGS, the configure script tries to test the flags with gfortran and not the specified compiler.

$ FC=flang FFLAGS="-march=znver2" ./configure --enable-lapack2flame
[...]
configure: FC environment variable is set to flang, which will override --with-fc option and default search list for Fortran compiler.
checking whether we are using the GNU Fortran compiler... no
checking whether flang accepts -g... yes
[...]
checking whether user requested auto-detection of Fortran linker flags... yes
checking whether user requested auto-detection of Fortran name-mangling... yes
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... gfortran
checking whether we are using the GNU Fortran 77 compiler... no
checking whether gfortran accepts -g... yes
checking how to get verbose linking output from gfortran... configure: WARNING: compilation failed

checking for Fortran 77 libraries of gfortran... 
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... configure: error: in `/expanse/lustre/projects/ucd150/mfehling/libflame':
configure: error: cannot compile a simple Fortran program
See `config.log' for more details

config.log
=======
[...]
configure:5336: checking for Fortran 77 name-mangling scheme
configure:5349: gfortran -c -march=znver2 conftest.f >&5
f951: Error: bad value ('znver2') for '-march=' switch
f951: note: valid arguments to '-march=' switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server bonnell atom silvermont slm knl knm x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 native; did you mean 'znver1'?
configure:5349: $? = 1
configure: failed program was:
|       subroutine foobar()
|       return
|       end
|       subroutine foo_bar()
|       return
|       end
configure:5482: error: in `.../libflame':
configure:5484: error: cannot compile a simple Fortran program
See `config.log' for more details
[...]

---

However, it works when I specify both FC and F77. Is this intended behavior?

$ FC=flang F77=flang FFLAGS="-march=znver2" ./configure --enable-lapack2flame

[marcfehling]

I think we need to be careful.

• F77 and FFLAGS correspond to Fortran 77
• FC and FCFLAGS correspond to Fortran (?)

They can both be different.

libflame/configure

Lines 1693 to 1710 in f38dd83

	Some influential environment variables:
	CC C compiler command
	CFLAGS C compiler flags
	LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
	nonstandard directory <lib dir>
	LIBS libraries to pass to the linker, e.g. -l<library>
	CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
	you have headers in a nonstandard directory <include dir>
	FC Fortran compiler command
	FCFLAGS Fortran compiler flags
	AR library archiver
	RANLIB library archive indexer
	PYTHON python interpreter
	FIND find utility
	XARGS xargs utility
	F77 Fortran 77 compiler command
	FFLAGS Fortran 77 compiler flags
	CPP C preprocessor

---

I am now specifying all four (FC, F77, FFLAGS, FCFLAGS) environmental variables and it seems to work.

[marcfehling]

At the linking stage, I now also get these errors related to the lapack library (when using --enable-dynamic-build).

Dynamically linking lib/x86_64-unknown-linux-gnu/libflame.so
ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in libflame.a(cbbcsd.o)
>>> referenced by cbbcsd.f:392 (src/map/common/lapacksrc/fortran/cbbcsd.f:392)
>>>               cbbcsd.o:(cbbcsd_) in archive libflame.a

[ItsPitt]

Currently only FC is supported for building the fortran files. Flags are not currently passed when building them.

libflame/Makefile

Lines 580 to 584 in f38dd83

	define fortran_rule
	$$(BASE_OBJ_PATH)/%.o: $$(SRC_PATH)/$1 $$(CONFIG_MK_FILE) $$(HEADERS_TO_FLATTEN) $$(BASE_OBJ_PATH)/la_xisnan.mod
	ifeq ($$(ENABLE_VERBOSE),yes)
	$(FC) -cpp -c $$< -o $$@
	else

Usage can be found here:

libflame/configure

Lines 1673 to 1676 in f38dd83

	--with-fc=fc Search for and use a Fortran compiler named <fc>. If
	<fc> is not found, then use the first compiler found
	from the default search list for the detected build
	architecture.

But it might also work in the method you've invoked it.

I think it is defaulting to FC because 'flang' is not in the list of FC options. Those can be found here:

libflame/configure

Line 3651 in f38dd83

fla_f_compiler_list="gfortran f77 g77 xlf frt pgf77 cf77 fort77 fl32 af77 xlf90 f90 pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn nagfor"

[marcfehling]

Currently only FC is supported for building the fortran files. Flags are not currently passed when building them.

Interesting. So the flags were only used for the internal autoconf checks, but not for building LAPACK!

---

I think it is defaulting to FC because 'flang' is not in the list of FC options.

In the first comment, I was specifying FC=clang and FFLAGS. However FFLAGS only applies to F77, which I didn't specify. So F77 defaulted to gfortran which is the first one in fla_f_compiler_list. On the machine I use, gfortran was too old to recognize -march=znver2, and that's what it complained about. Interesting, thanks for pointing that out!

It seems like autoconf treats Fortran and Fortran 77 compilers separately, which I was not aware of. So FC is used in combination with FCFLAGS, and F77 is used in combination with FFLAGS.

Since you only use FC to build LAPACK, how do you think about removing all Fortran 77 related things in your configure script? This would avoid ambiguity.

Also, building LAPACK with FCFLAGS would be a nice feature.

[ItsPitt]

Adding FCFLAGS to building LAPACK is something I will discuss with others. I see how it would be helpful.

Were you able to get your linkage issue resolved?