|
|
 Up |
|
|
  |
Author: s8ngsu3s8ngsu3 Date: Jan 22, 2008 03:58
How come the .mod files are not compatible between different
compilers? E.g., a .mod file produced by Intel Fortran Compiler
(ifort) cannot be used by g95, etc. It's very cumbersome when
installing some libraries with Fortran bindings - even if the library
has been compiled and all the required .mod files are already there,
it must be recompiled again in order to be used by a different
compiler. Why isn't there a common format for these files (or maybe
there is and I just overlooked smth)?
|
| |
|
| | 9 Comments |
|
|
Author: FXFX Date: Jan 22, 2008 04:10
> Why isn't there a common format for these files (or maybe there is and
> I just overlooked smth)?
No, you haven't overlooked anything, there is no common format for
generated module files. The reason is probably that the standard doesn't
specify one, which means it is not supposed to be used in such a way.
What your libraries should provide is a source file containing all the
relevant definitions and interfaces, much like C libraries provide header
files (usually with extension .h).
--
FX
|
| |
|
| | no comments |
|
|
Author: Gordon SandeGordon Sande Date: Jan 22, 2008 06:10
On 2008-01-22 07:58:22 -0400, s8ngsu3@ yahoo.com said:
> How come the .mod files are not compatible between different
> compilers? E.g., a .mod file produced by Intel Fortran Compiler
> (ifort) cannot be used by g95, etc. It's very cumbersome when
> installing some libraries with Fortran bindings - even if the library
> has been compiled and all the required .mod files are already there,
> it must be recompiled again in order to be used by a different
> compiler. Why isn't there a common format for these files (or maybe
> there is and I just overlooked smth)?
Perhaps for the same reason that the object files are not compatible
between compilers. Or have you not yet been bitten by that?
Object files are not compatible because:
1. the run time libraries may be (and often are) different
2. the low level calling conventions may be (and often are) different
3. etc
as has been the case for a long time. That is why there is
typically a separate version of a subroutine library for each
Fortran compiler vendor.
|
| Show full article (1.45Kb) |
| no comments |
|
|
Author: nospamnospam Date: Jan 22, 2008 08:26
Gordon Sande worldnet.att.net> wrote:
> There is so little requirement on .mod files that it is
> even a wonder that they are even given similar names.
They didn't used to be. Sun (inherited from Cray, I understand) used to
use a completely different system where the module information was in
the object file - I think that was it. I believe they were pushed by
user pressure to the now defacto standard file naming convention.
Also, there have been Dos/Windows implementations that used a more
complicated scheme to work around file name limitations in the OS.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
| |
| no comments |
|
|
Author: Paul van DelstPaul van Delst Date: Jan 22, 2008 09:01
Richard Maine wrote:
> Gordon Sande worldnet.att.net> wrote:
> >> There is so little requirement on .mod files that it is
>> even a wonder that they are even given similar names.
>
> They didn't used to be. Sun (inherited from Cray, I understand) used to
> use a completely different system where the module information was in
> the object file - I think that was it. I believe they were pushed by
> user pressure to the now defacto standard file naming convention.
Some of my make files still handle any variant of *.m, *.M, *.mod and *.MOD. I've seen all
except the *.M (I simply added it for symmetry).
ISTR the very first Intel fortran compiler release (back when it was called ifc) creating
something called *.pfc files. Or was it some other vendor?
Recently, all the compilers I use now seem to have standardised on *.mod.
cheers,
paulv
|
| Show full article (1.00Kb) |
| no comments |
|
|
Author: mecej4mecej4 Date: Jan 24, 2008 05:01
Paul van Delst wrote:
> Richard Maine wrote:
>> Gordon Sande worldnet.att.net> wrote:
>>>>> There is so little requirement on .mod files that it is
>>> even a wonder that they are even given similar names.
>>
>> They didn't used to be. Sun (inherited from Cray, I understand) used to
>> use a completely different system where the module information was in
>> the object file - I think that was it. I believe they were pushed by
>> user pressure to the now defacto standard file naming convention.
>
> Some of my make files still handle any variant of *.m, *.M, *.mod and
> *.MOD. I've seen all except the *.M (I simply added it for symmetry).
>
> ISTR the very first Intel fortran compiler release (back when it was
> called ifc) creating something called *.pfc files. Or was it some other
> vendor?
>
> Recently, all the compilers I use now seem to have standardised on *.mod. ...
|
| Show full article (1.04Kb) |
| no comments |
|
|
Author: Paul van DelstPaul van Delst Date: Jan 24, 2008 06:14
mecej4 wrote:
> Paul van Delst wrote:
>> Richard Maine wrote:
>>> Gordon Sande worldnet.att.net> wrote:
>>>>>>> There is so little requirement on .mod files that it is
>>>> even a wonder that they are even given similar names.
>>>
>>> They didn't used to be. Sun (inherited from Cray, I understand) used to
>>> use a completely different system where the module information was in
>>> the object file - I think that was it. I believe they were pushed by
>>> user pressure to the now defacto standard file naming convention.
>>
>> Some of my make files still handle any variant of *.m, *.M, *.mod and
>> *.MOD. I've seen all except the *.M (I simply added it for symmetry).
>>
>> ISTR the very first Intel fortran compiler release (back when it was
>> called ifc) creating something called *.pfc files. Or was it some
>> other vendor?
>> ...
|
| Show full article (1.49Kb) |
| no comments |
|
|
Author: Fly AwayFly Away Date: Jan 24, 2008 08:50
On Jan 24, 7:14 am, Paul van Delst noaa.gov> wrote:
>
> Better yet, don't use .mod suffixes in your Fortran95 makefiles.
I think it is a bad advice. .mod files are dependancies and have to be
recreated in many cases. If you do not account for such cases in your
building script, be it a makefile or something else, you might get
errors.
The following like was posted on c.l.f some time ago:
http://www.nicdan.id.au/computers/compiling/recompile.html
It addresses the issue of including .mod files in makefiles and
avoiding unnecessary recompilation.
Cheers,
Victor.
|
| |
| no comments |
|
|
Author: Gordon SandeGordon Sande Date: Jan 24, 2008 09:48
> On Jan 24, 7:14 am, Paul van Delst noaa.gov> wrote:
> >>
>> Better yet, don't use .mod suffixes in your Fortran95 makefiles.
>
> I think it is a bad advice. .mod files are dependancies and have to be
> recreated in many cases. If you do not account for such cases in your
> building script, be it a makefile or something else, you might get
> errors.
> The following like was posted on c.l.f some time ago:
> http://www.nicdan.id.au/computers/compiling/recompile.html
> It addresses the issue of including .mod files in makefiles and
> avoiding unnecessary recompilation.
>
> Cheers,
> Victor.
|
| Show full article (1.57Kb) |
| no comments |
|
|
|
|
|
Author: Craig PowersCraig Powers Date: Jan 24, 2008 11:50
Fly Away wrote:
> On Jan 24, 7:14 am, Paul van Delst noaa.gov> wrote:
> >> Better yet, don't use .mod suffixes in your Fortran95 makefiles.
>
> I think it is a bad advice. .mod files are dependancies and have to be
> recreated in many cases.
My makefiles handle module dependencies through a script that scans
through source files for USE statements and makes the using file depend
on the corresponding object file (not the mod file). It works fine if
the compiler regenerates the .mod file every time it recompiles the
source, but would be suboptimal otherwise. (So if my compilers were to
avoid unnecessarily regenerating .mod files, which I don't think they do
now, I might change it.)
|
| |
| no comments |
|
|
