search

conda-forge / ctng-compiler-activation-feedstock

A conda-smithy repository for ctng-compiler-activation.
BSD 3-Clause "New" or "Revised" License
13 stars 26 forks source link

GFortran cannot find installed .mod files #124

Open LourensVeen opened 3 months ago

LourensVeen commented 3 months ago

Comment:

Fortran libraries that use modules need to install either a source file or a .mod file in a place where it can be found. For conda-forge, this is the /include directory in the environment (according to @isuruf). The activation scripts for Fortran add this location to the FFLAGS using -isystem, but GFortran doesn't search that directory for .mod files, so they aren't found.

For MPI there's a compiler wrapper that adds the path with -I, and HDF5 has a compiler wrapper as well that can produce additional include paths and is used for that by the popular build systems, but it doesn't make sense to supply a special tool with every library. (Anyway there's pkg-config, but Conda doesn't add the conda environment to the pkg-config search path either, and not every library supports it.)

Isuru suggested adding -J $PREFIX/include to FFLAGS in the activation script. I think -I $PREFIX/include may be a better solution however. The documentation says that -J adds the directory to the search path, but it also directs the compiler to put the created .mod files there. That would mean every compile step is now also an installation step, and that you may get a pile of .mods for library-internal modules.

-I sets not just the search path for .mod files but also for files included using the INCLUDE statement, and for the preprocessor's #include, but at least it doesn't tell the compiler to write anything there. So I think it's the better option here.

LourensVeen commented 3 months ago

The plot thickens...

I'm trying to compile HDF5 1.12 using a conda-installed compiler and mpich. The conda environment has hdf5 1.14.3 installed in it. When the HDF5 build system gets to building the tests, it adds -I options to the compiler command line to point to the .mod files of the compiled library it just made.

As mentioned above, the conda mpich mpif90 compiler wrapper adds a -I$PREFIX/include to the compiler command it calls internally, so that the .mod files for the MPI library can be found. This injects -I$PREFIX/include before the -I statements the build system adds, causing the compiler to find the .mod that came with the conda-installed HDF5 1.14.3, which is this case resulted in a .o file with an undefined symbol that didn't occur anywhere in the source or in the conda env (.mod files seem to be obfuscated, so it's probably in there but grep didn't find it).

We don't have that problem in C or C++, because we can use -isystem there, and -I goes before -isystem every time.

I'm not sure what to do next. Ask the gfortran maintainers to search -isystem paths for Fortran .mod files? Ask them to add a -ifsystem option specifically for .mod files? There doesn't seem to exist a working solution as is.