X-Spam-Check-By: sourceware.org
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
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
Precedence: bulk
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
Content-Transfer-Encoding: 8bit
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/