From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 23932383F864; Mon, 4 May 2020 08:23:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 23932383F864 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1588580597; bh=VyCZHJjfdVWqzOYDhXnl7Ts1y+oWASpmiYQZXNJhrv4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I/29g+TKonJ1LSKRqdHpt3K2FR9Nx2+439bMXRhLvoujc4x9lAO4NympDI7Wuri35 nIkyTIAF3KcHqYtDSnRNkNRHM/BmCAetT9iq0cIQlNnZyQdOcJvjICKFsCF0wJz2C1 cwdYjLn54tUS+K8YYK6zLDdfOyc+nPsXUJyfJyds= From: "ryofurue at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/94931] request: print include path Date: Mon, 04 May 2020 08:23:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ryofurue at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:23:17 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94931 --- Comment #6 from Ryo Furue --- Thanks again for your comments! > For a software developer, I > would put the libraries in ${INSTALLDIR}/lib and modules > in ${INSTALLDIR?/modules. INSTALLDIR could be /usr/local, > and, of course, you would describe this in the user and > installation manuals. I see. So, the directory gfortran searches by default is not intended for non-gfortran libraries. I'm definitely drifting off-topic, but my question/request stemmed from the fact that I initially didn't know why=20 gfortran mysourcefile.f -lnetcdff -netcdff didn't find /usr/include/netcdf.inc . I thought somethig was wrong. In hindsight, it's because gfortran doesn't search /usr/include/ . So, eventu= ally I learned that gfortran -I/usr/include mysourcefile.f -lnetcdff -lnetcdf is the answer. But, then the question is, why don't you need the -L option? as in gfortran -I/usr/include mysourcefile.f -L/usr/lib -lnetcdff -netcdf Why is this asymmetry? It seems that there are "standard" places to place libraries but not include files . . .=20 I'm not blaming gfortran at all. I'm just wondering what I should say to the packager of the netCDF library (or what I should do, if I were to package t= his library). Returning to the original issue: Although I led you in the wrong direction (--print-search-dir, and I'm sorry about that), my original request may not= be invalid: I think it would be nice if the answer(*) is available somewhere, either in the form of an output from a command line option or in the offici= al document or somewhere. (*) the answer to the question: where does gfortran search for include file= s by default? (Answer: the current directory and an internal directory where gfortran's internal modules are stored.)=