[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] fortran .mod files



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]