On Tue, 2007-10-23 at 07:19 -0400, Jakub Jelinek wrote:
On Tue, Oct 23, 2007 at 05:33:11AM +0200, Ralf Corsepius wrote:
> On Mon, 2007-10-22 at 16:50 -0400, Tom "spot" Callaway wrote:
> > On Mon, 2007-10-22 at 22:49 +0200, Patrice Dumas wrote:
> > > %{_libdir}/gfortran/modules
> >
> > ^^^ I like this the best so far.
> Well, it actually is irrelevant what we think.
>
> gfortran should have a default search path being implied by f90, and it
> there where packages should install it's *.mod's into.
>
> If gfortran doesn't have a default search path, this would qualify as a
> bug in gcc-gfortran.
`gcc $RPM_OPT_FLAGS -print-file-name=finclude`
(which is /usr/lib/gcc/*-redhat-linux/*/finclude ).
OK this is what I had presumed
to be a GCC-internal/private directory.
This is a compiler version and arch dependent path, but *.mod files
are heavily compiler version dependent.
Hmm, ...
But I guess I'll need to make some changes, because say on
i386 this is /usr/lib/gcc/i386-redhat-linux/4.1.2/finclude,
while on x86_64 for 32-bit rpms
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/finclude/ )
What I was referring to (and
implicitly proposing) was GCC/gfortran to
be extended to have a "standard, system-wide, GCC-independent" *.mod
installation directory/*.mod-search path, similar to /usr/include for
cpp'ed sources (c/c++-headers).
But ... if, as you say, *.mod's are really are compiler-dependent, then
gcc-gfortran(f90) has a real problem.
Ralf