[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_FC_MODULE_FLAG
From: |
Ralf Wildenhues |
Subject: |
Re: AC_FC_MODULE_FLAG |
Date: |
Wed, 06 Jul 2011 22:15:08 +0200 |
Hi Jim,
thanks for the bug report!
* Jim Edwards wrote on Wed, Jul 06, 2011 at 08:00:13PM CEST:
> When using the lahey fortran compiler the flag -M is used as the path to
> modules, but its also the path to where new modules should be written.
> So if you are referencing modules in a read-only directory using the -M flag
> will cause your program to fail. I think that the solution is to
> test for -I first (that's also the most common result, so it would make
> sense to test first I think)
Well, with Solaris Fortran, -I is the flag to search for both header
includes as well as modules, but it also has -M for module search path
only. I'm kind of wary that if some command-line gets hardcoded -M
flags from elsewhere, they could then end up overriding the ones
computed by configure, although they come later in the command-line.
Can we fix the test somehow so that -M is not chosen with Lahey? Adding
the flag twice worked for some compiler at least. Could also test
whether the compiler creates a module somewhere. Care to experiment a
bit to find something that works with your compiler? (I don't have
Lahey to test.)
> --- fortran.m4 (revision 327)
> +++ fortran.m4 (working copy)
> @@ -618,7 +618,7 @@
> [cd ..
> ac_fc_module_flag_FCFLAGS_save=$FCFLAGS
> # Flag ordering is significant for gfortran and Sun.
> - for ac_flag in -M -I '-I ' '-M ' -p '-mod ' '-module ' '-Am -I'; do
> + for ac_flag in -I '-mod ' -I '-I ' '-M ' -p '-module ' '-Am -I'; do
> # Add the flag twice to prevent matching an output flag.
> FCFLAGS="$ac_fc_module_flag_FCFLAGS_save ${ac_flag}conftest.dir
> ${ac_flag}conftest.dir"
> AC_COMPILE_IFELSE([[
Thanks,
Ralf