There is a serious lack of a default-searched location for Fortran include files - and in particular for Fortran .mod files. The latter is particularly important as different compilers/different versions have different .mod files. Currently, Linux distributions usually either do not ship .mod files or they ship them simply in /usr/include. The /usr/{local/,}include/fortran/ directory should be used (and searched) for Fortran INCLUDE / #include files. Module files (or arch-dependent include files) should be searched for in an compiler/architecture-dependent subdirectory, which can be queried with -print-mod-dir-suffix: gfortran $(FFLAGS) -print-mod-dir-suffix (Note: -m... flags in the $(FFLAGS) might change the result.) Thus, the search order is: LOCAL_INCLUDE_DIR/fortran/$(gfortran -print-mod-dir-suffix) # .mod files LOCAL_INCLUDE_DIR/fortran # include files LOCAL_INCLUDE_DIR # For backward compatibility followed by the same order for SYSTEM_INCLUDE_DIR and then STANDARD_INCLUDE_DIR The result of -print-mod-dir-suffix should be gcc-<module_version>/lib{,<qual>} The reason for "lib{,<qual>}" is to allow for architecture-defined directories; using directly the target (e.g. x86_64-unknown-linux-gnu) instead of the lib won't work as for x86_64 one can have -m32 and -m64 but target remains the same, while for i686 and x86_64 -m32, the target changes but the produced binaries are the same. Additionally, for PowerPC, the default can be 32 or 64 bit. For the FHS standard tacking, see: http://bugs.linux-foundation.org/show_bug.cgi?id=757 (The proposal was discussed with Jakub, Richard and Matthias.)
On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote: > The /usr/{local/,}include/fortran/ directory should be used (and searched) for > Fortran INCLUDE / #include files. The Fortran directories should be searched within the sysroot when there is one (the same conditions under which such C directories are searched within the sysroot). > The result of -print-mod-dir-suffix should be > gcc-<module_version>/lib{,<qual>} > > The reason for "lib{,<qual>}" is to allow for architecture-defined directories; By "lib{,<qual>}" do you mean lib/$(gcc -print-multi-os-directory) ? (Inventing yet another system for distinguishing multilibs, when there's already -print-multi-directory and -print-multi-os-directory, seems like a bad idea.)
(In reply to comment #1) > The Fortran directories should be searched within the sysroot when there > is one (the same conditions under which such C directories are searched > within the sysroot). OK, one then has the "fortran" subdirectory of: sysroot, LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR - in that order. Is the list complete and correctly ordered? > > The result of -print-mod-dir-suffix should be > > gcc-<module_version>/lib{,<qual>} > > By "lib{,<qual>}" do you mean lib/$(gcc -print-multi-os-directory) ? Yes - although using -print-multi-directory instead would be probably better as it avoid the misleading "lib". Thus, instead of, e.g., ./lib32/ and ./lib/, one has ./ and ./32/. Thanks for your comments!
On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138 > > --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-24 14:54:03 UTC --- > (In reply to comment #1) > > The Fortran directories should be searched within the sysroot when there > > is one (the same conditions under which such C directories are searched > > within the sysroot). > > OK, one then has the "fortran" subdirectory of: sysroot, LOCAL_INCLUDE_DIR, > SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR - in that order. Is the list > complete and correctly ordered? I advise following cppdefault.c (specifically, the add_sysroot flags therein) - and probably adding a "fortran" field to indicate if a Fortran subdirectory is searched, rather than duplicating the list.
Isn't this the same as #35707?
(In reply to comment #4) > Isn't this the same as bug #35707? Hmm, maybe. I think strictly speaking they are different issues, but both try to solve the same problem.
See also: - http://fedoraproject.org/wiki/PackagingDrafts/FortranLibraries (from 2008) - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714730 + http://lists.debian.org/debian-science/2013/07/msg00012.html
Let me mark this PR as duplicate of pr35707 (no need to have two inactive PRs opened). *** This bug has been marked as a duplicate of bug 35707 ***