[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Ralf Wildenhues
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"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]