X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
Subject:	RE: Fortran Compiler Error CMBFAST
Date:	Tue, 27 Jun 2006 17:59:11 -0400
Message-ID:	<4C89134832705D4D85A6CD2EBF38AE0F549824@PAUMAILU03.ags.agere.com>
In-Reply-To:	<03a101c699f7$71c53800$a501a8c0@CAM.ARTIMI.COM>
From:	"Williams, Gerald S \(Jerry\)" <gsw AT agere DOT com>
To:	"Cygwin General List" <cygwin AT cygwin DOT com>
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id k5RLxQj8004592

Dave Korn wrote:
>   We *need* to see the actual command line.

That was in the original post (sorry, I should have made
sure it was included in the text when I CC'ed you...):

> f77 -O2   -c -o jlgen.o jlgen.F

The command was being executed from the same directory
as jlgen.F, which also contains the include file that
it cannot find. Adding -I. to the command line fixes
the problem.

The OP didn't provide enough information about where
the files resided, but I downloaded the CMBFAST package
myself and verified that "./configure && make" results
in the same error. I also verified that it builds if
you manually compile with "-I." (or add -I. to FFLAGS
in the makefile).

> Is everyone in this thread aware of the effects of
> -I- [...]

I assume that's not relevant since -I- is not used.

> It needs to be pointed out that adding "-I." doesn't
> help any if you aren't building in the source dir but
> a parallel object dir...

True. This was a workaround for this specific case. In
general, you would want to use -I$(SRCDIR) or something
along those lines, although technically I don't think
you should need to do either. :-)

------

I just recreated the problem with some minimal code,
and got some more information in the process:

Create a file "foo.for" that contains one line:
        include 'foo.inc'

Create an empty file named foo.inc in the same
directory.

Copy "foo.for" to "foo.f", "foo.FOR", and "foo.F" and
try to compile all four of them from that directory:

$ f77 -c foo.for    # runs OK
$ f77 -c foo.f      # runs OK
$ f77 -c foo.FOR    # runs OK
$ f77 -c foo.F
foo.F:1:
           include 'foo.inc'
           ^
Unable to open INCLUDE file `foo.inc' at (^)
$ _

So it seems that the rules by which the preprocessor
looks in the current directory and/or the directory
containing the source file does not apply to files
named *.F for some reason. It's possible that this
was intentional, although I don't get this behavior
on my Linux box (which granted is using GCC version
3.2.3, so it could have changed since then...).

gsw

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -