From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31815 invoked by alias); 2 May 2010 14:32:14 -0000 Received: (qmail 31772 invoked by uid 48); 2 May 2010 14:32:03 -0000 Date: Sun, 02 May 2010 14:32:00 -0000 Message-ID: <20100502143203.31769.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00110.txt.bz2 ------- Comment #12 from burnus at gcc dot gnu dot org 2010-05-02 14:32 ------- (In reply to comment #11) > Consensus seems to be: no, do not search the system include paths. > > Set status to WAITING. To be closed as INVALID(?) in three months from now if > there is no further discussion. > Shall this be noted in the man page? It currently reads as follows which implies that "include" and "#include" are strongly tied? -Idir These affect interpretation of the "INCLUDE" directive (as well as of the "#include" directive of the cpp preprocessor). Also note that the general behavior of -I and "INCLUDE" is pretty much the same as of -I with "#include" in the cpp preprocessor, with regard to looking for header.gcc files and other such things. This path is also used to search for .mod files when previously compiled modules are required by a "USE" statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707