Do different compilers produce different .mod files? 
Author Message
 Do different compilers produce different .mod files?

Hello,
I'm trying to add HDF5 to a program and i am using the binary
libraries from the website.
However when i try to compile the program neither ifort (intel) or f95
(sun) will recognise the .mod files from the api that came with the
libraries. The libraries were compiled with G95 i think. Does anyone
know if G95 .mod files should be compatible with other compilers? i
would have though so.

Also has anyone managed to get the api that comes with the HDF5
library to work with other compilers?

Thanks

Jeremy



Sun, 22 Aug 2010 03:05:43 GMT  
 Do different compilers produce different .mod files?

Quote:

> Does anyone
> know if G95 .mod files should be compatible with other compilers? i
> would have though so.

No. The .mod files are compiler-specific. Heck, it is even
compiler-specific whether there is such a thing as a .mod file. Putting
the necessary information in a .mod file is the most common
implementation scheme - enough so to have become a bit of a defacto
standard - but it is not the only scheme.

It has even happened that .mod files are incompatible between different
versions of the same compiler... just like it has happened that object
files have beeen simillarly incompatible. Vendors try to avoid such
version incompatibilities (because it makes life difficult for
customers, who then in turn make life difficult for the vendors), but it
has happened.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain



Sun, 22 Aug 2010 03:21:11 GMT  
 Do different compilers produce different .mod files?

Quote:

> > Does anyone
> > know if G95 .mod files should be compatible with other compilers? i
> > would have though so.

> No. The .mod files are compiler-specific. Heck, it is even
> compiler-specific whether there is such a thing as a .mod file. Putting
> the necessary information in a .mod file is the most common
> implementation scheme - enough so to have become a bit of a defacto
> standard - but it is not the only scheme.

> It has even happened that .mod files are incompatible between different
> versions of the same compiler... just like it has happened that object
> files have beeen simillarly incompatible. Vendors try to avoid such
> version incompatibilities (because it makes life difficult for
> customers, who then in turn make life difficult for the vendors), but it
> has happened.

Such incompatibilities usually imply to me less than ideal design of
the .mod file structure.  There's almost never good justification for
such incompatibilities.  It is sometimes due to laziness, for example
creating the file structure as a sequence of structures with no
tagging/markup whatsoever.  A tiny bit of thought, such as tagging
(e.g. escape sequences but a little more sophisticated), can avoid all
incompatibilities, and with minimal I/O performance impact (slightly
more difficult to process tho).

- Show quoted text -

Quote:
> --
> Richard Maine ? ? ? ? ? ? ? ? ? ?| Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle ? ? ? ? ? | ?-- Mark Twain



Sun, 22 Aug 2010 04:12:12 GMT  
 Do different compilers produce different .mod files?
When I used HDF5, I used to compile HDF5 with various fortran
compilers :
that should not be an issue for you. We had the rule to identify the
binaries and the .mod with a full path like :
lib/linux-ix86/gfortran4.1/debug
lib/linux-ix86/intel8.1/debug
so that afterwards you can know the compiler you used or change the
compiler if you have to.
But I do not understand that the .mod are distributed with hdf5
without
a clear indication, since they are compiler-specific.
Don't you have any information on the compiler that
was used (you say "I think" which seems vague to me) ?

Best regards,

Micha?l



Sun, 22 Aug 2010 04:19:38 GMT  
 Do different compilers produce different .mod files?

Quote:


>>> Does anyone
>>> know if G95 .mod files should be compatible with other compilers? i
>>> would have though so.

>> No. The .mod files are compiler-specific. Heck, it is even
>> compiler-specific whether there is such a thing as a .mod file. Putting
>> the necessary information in a .mod file is the most common
>> implementation scheme - enough so to have become a bit of a defacto
>> standard - but it is not the only scheme.

>> It has even happened that .mod files are incompatible between different
>> versions of the same compiler... just like it has happened that object
>> files have beeen simillarly incompatible. Vendors try to avoid such
>> version incompatibilities (because it makes life difficult for
>> customers, who then in turn make life difficult for the vendors), but it
>> has happened.

> Such incompatibilities usually imply to me less than ideal design of
> the .mod file structure.  There's almost never good justification for
> such incompatibilities.  It is sometimes due to laziness, for example
> creating the file structure as a sequence of structures with no
> tagging/markup whatsoever.  A tiny bit of thought, such as tagging
> (e.g. escape sequences but a little more sophisticated), can avoid all
> incompatibilities, and with minimal I/O performance impact (slightly
> more difficult to process tho).

The information that a compiler wants to obtain from a USE statement
could be as little as some symbols with a small of amount of additional
information or as much as the full source of the module. There is no
single design that could meet such varying objectives. The Fortran
specification does not say what is there and the actual contents would
depend upon how agressive the compiler implementors choose to be in
being able to analyse the whole program. Those with minor requirements
would certainly object to servicing the needs of those with much more
extensive requirements.

If one were running a Fortran interpreter the USE statement would want
the full source (or functional equivalent) to allow the current program
to be interpreted.

It is a real pain to recompile those old CDC6600 object files to run
on a PC but it is an incompatability that folks have learned to live with.
I do not recall seeing such a complaint in this newsgroup!

- Show quoted text -

Quote:
>> --
>> Richard Maine ? ? ? ? ? ? ? ? ? ?| Good judgement come
> s from experience;
>> email: last name at domain . net | experience comes from bad judgement.
>> domain: summertriangle ? ? ? ? ? | ?-- Mark Twain



Sun, 22 Aug 2010 04:32:16 GMT  
 Do different compilers produce different .mod files?

Quote:



>>> Does anyone
>>> know if G95 .mod files should be compatible with other compilers? i
>>> would have though so.
>> No. The .mod files are compiler-specific. Heck, it is even
>> compiler-specific whether there is such a thing as a .mod file. Putting
>> the necessary information in a .mod file is the most common
>> implementation scheme - enough so to have become a bit of a defacto
>> standard - but it is not the only scheme.

>> It has even happened that .mod files are incompatible between different
>> versions of the same compiler... just like it has happened that object
>> files have beeen simillarly incompatible. Vendors try to avoid such
>> version incompatibilities (because it makes life difficult for
>> customers, who then in turn make life difficult for the vendors), but it
>> has happened.

> Such incompatibilities usually imply to me less than ideal design of
> the .mod file structure.  There's almost never good justification for
> such incompatibilities.  It is sometimes due to laziness, for example
> creating the file structure as a sequence of structures with no
> tagging/markup whatsoever.  A tiny bit of thought, such as tagging
> (e.g. escape sequences but a little more sophisticated), can avoid all
> incompatibilities, and with minimal I/O performance impact (slightly
> more difficult to process tho).

I would blame the marketing dept for a dearth of foresight before I would the compiler
writers....

I mean, who hasn't prototyped code that has unintentionally escaped its enclosure?  :o)

cheers,

paulv



Sun, 22 Aug 2010 04:56:58 GMT  
 Do different compilers produce different .mod files?

Quote:

<snip>
> > Such incompatibilities usually imply to me less than ideal design of
> > the .mod file structure. ?There's almost never good justification for
> > such incompatibilities. ?It is sometimes due to laziness, for example
> > creating the file structure as a sequence of structures with no
> > tagging/markup whatsoever. ?A tiny bit of thought, such as tagging
> > (e.g. escape sequences but a little more sophisticated), can avoid all
> > incompatibilities, and with minimal I/O performance impact (slightly
> > more difficult to process tho).

> The information that a compiler wants to obtain from a USE statement
> could be as little as some symbols with a small of amount of additional
> information or as much as the full source of the module. There is no
> single design that could meet such varying objectives. The Fortran
> specification does not say what is there and the actual contents would
> depend upon how agressive the compiler implementors choose to be in
> being able to analyse the whole program. Those with minor requirements
> would certainly object to servicing the needs of those with much more
> extensive requirements.

> If one were running a Fortran interpreter the USE statement would want
> the full source (or functional equivalent) to allow the current program
> to be interpreted.

> It is a real pain to recompile those old CDC6600 object files to run
> on a PC but it is an incompatability that folks have learned to live with.
> I do not recall seeing such a complaint in this newsgroup!

<snip>

File format designs that I'm familiar with, tag every single piece of
data and potentially include version information.  It doesnt' really
matter if the data itself needed by the compiler is simple or
complex.  If every piece of data is properly tagged, it can always be
processed as originally intended.  Object files are not examples of
fully tagged data.  Nor is any file that assumes particular content by
mere position of the data within a file or within a record.  Few of
today's common file formats (.wav, .jpg, .png) are fully tagged either
(and some are in my opinion somewhat poorly designed).



Sun, 22 Aug 2010 07:16:07 GMT  
 Do different compilers produce different .mod files?

Quote:


> <snip>
>>> Such incompatibilities usually imply to me less than ideal design of
>>> the .mod file structure. ?There's almost never good justification for
>>> such incompatibilities. ?It is sometimes due to laziness, for example
>>> creating the file structure as a sequence of structures with no
>>> tagging/markup whatsoever. ?A tiny bit of thought, such as tagging
>>> (e.g. escape sequences but a little more sophisticated), can avoid all
>>> incompatibilities, and with minimal I/O performance impact (slightly
>>> more difficult to process tho).

>> The information that a compiler wants to obtain from a USE statement
>> could be as little as some symbols with a small of amount of additional
>> information or as much as the full source of the module. There is no
>> single design that could meet such varying objectives. The Fortran
>> specification does not say what is there and the actual contents would
>> depend upon how agressive the compiler implementors choose to be in
>> being able to analyse the whole program. Those with minor requirements
>> would certainly object to servicing the needs of those with much more
>> extensive requirements.

>> If one were running a Fortran interpreter the USE statement would want
>> the full source (or functional equivalent) to allow the current program
>> to be interpreted.

>> It is a real pain to recompile those old CDC6600 object files to run
>> on a PC but it is an incompatability that folks have learned to live with.

>> I do not recall seeing such a complaint in this newsgroup!

> <snip>

> File format designs that I'm familiar with, tag every single piece of
> data and potentially include version information.  It doesnt' really
> matter if the data itself needed by the compiler is simple or
> complex.  If every piece of data is properly tagged, it can always be
> processed as originally intended.  Object files are not examples of
> fully tagged data.  Nor is any file that assumes particular content by
> mere position of the data within a file or within a record.  Few of
> today's common file formats (.wav, .jpg, .png) are fully tagged either
> (and some are in my opinion somewhat poorly designed).

Your complaint would make sense if the semantics of the .mod were constant
over compilers. It isn't. So complaints about poor syntax miss the mark even
if they were true.

Those with simple semantics will not meet the needs of those that require
more complex semantics whatever syntax your might care to have them use.

You do not use a VW Beetle to take your sports team across town even if
the Beetle is in the team colors. Your complaint is the analogue of asking
for the right team colors when there is no chance they will fit inside.



Sun, 22 Aug 2010 07:30:44 GMT  
 Do different compilers produce different .mod files?

Quote:




>> <snip>

>>>> Such incompatibilities usually imply to me less than ideal design of
>>>> the .mod file structure.  There's almost never good justification for
>>>> such incompatibilities.  It is sometimes due to laziness, for example
>>>> creating the file structure as a sequence of structures with no
>>>> tagging/markup whatsoever.  A tiny bit of thought, such as tagging
>>>> (e.g. escape sequences but a little more sophisticated), can avoid all
>>>> incompatibilities, and with minimal I/O performance impact (slightly
>>>> more difficult to process tho).

>>> The information that a compiler wants to obtain from a USE statement
>>> could be as little as some symbols with a small of amount of additional
>>> information or as much as the full source of the module. There is no
>>> single design that could meet such varying objectives. The Fortran
>>> specification does not say what is there and the actual contents would
>>> depend upon how agressive the compiler implementors choose to be in
>>> being able to analyse the whole program. Those with minor requirements
>>> would certainly object to servicing the needs of those with much more
>>> extensive requirements.

>>> If one were running a Fortran interpreter the USE statement would want
>>> the full source (or functional equivalent) to allow the current program
>>> to be interpreted.

>>> It is a real pain to recompile those old CDC6600 object files to run
>>> on a PC but it is an incompatability that folks have learned to live
>>> with.

>>> I do not recall seeing such a complaint in this newsgroup!

>> <snip>

>> File format designs that I'm familiar with, tag every single piece of
>> data and potentially include version information.  It doesnt' really
>> matter if the data itself needed by the compiler is simple or
>> complex.  If every piece of data is properly tagged, it can always be
>> processed as originally intended.  Object files are not examples of
>> fully tagged data.  Nor is any file that assumes particular content by
>> mere position of the data within a file or within a record.  Few of
>> today's common file formats (.wav, .jpg, .png) are fully tagged either
>> (and some are in my opinion somewhat poorly designed).

> Your complaint would make sense if the semantics of the .mod were constant
> over compilers. It isn't. So complaints about poor syntax miss the mark
> even
> if they were true.

> Those with simple semantics will not meet the needs of those that require
> more complex semantics whatever syntax your might care to have them use.

> You do not use a VW Beetle to take your sports team across town even if
> the Beetle is in the team colors. Your complaint is the analogue of asking
> for the right team colors when there is no chance they will fit inside.

I was referring specifically to backward compatibility within the same
compiler system caused by the revision cycle.  However, the above could
in fact be fully applied across compiler systems if there were a will to
do so.

--

Gary Scott

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford



Sun, 22 Aug 2010 08:25:39 GMT  
 Do different compilers produce different .mod files?

Quote:




>>> <snip>

>>>>> Such incompatibilities usually imply to me less than ideal design of
>>>>> the .mod file structure.  There's almost never good justification for
>>>>> such incompatibilities.  It is sometimes due to laziness, for example
>>>>> creating the file structure as a sequence of structures with no
>>>>> tagging/markup whatsoever.  A tiny bit of thought, such as tagging
>>>>> (e.g. escape sequences but a little more sophisticated), can avoid all
>>>>> incompatibilities, and with minimal I/O performance impact (slightly
>>>>> more difficult to process tho).

>>>> The information that a compiler wants to obtain from a USE statement
>>>> could be as little as some symbols with a small of amount of additional
>>>> information or as much as the full source of the module. There is no
>>>> single design that could meet such varying objectives. The Fortran
>>>> specification does not say what is there and the actual contents would
>>>> depend upon how agressive the compiler implementors choose to be in
>>>> being able to analyse the whole program. Those with minor requirements
>>>> would certainly object to servicing the needs of those with much more
>>>> extensive requirements.

>>>> If one were running a Fortran interpreter the USE statement would want
>>>> the full source (or functional equivalent) to allow the current program
>>>> to be interpreted.

>>>> It is a real pain to recompile those old CDC6600 object files to run
>>>> on a PC but it is an incompatability that folks have learned to live with.

>>>> I do not recall seeing such a complaint in this newsgroup!

>>> <snip>

>>> File format designs that I'm familiar with, tag every single piece of
>>> data and potentially include version information.  It doesnt' really
>>> matter if the data itself needed by the compiler is simple or
>>> complex.  If every piece of data is properly tagged, it can always be
>>> processed as originally intended.  Object files are not examples of
>>> fully tagged data.  Nor is any file that assumes particular content by
>>> mere position of the data within a file or within a record.  Few of
>>> today's common file formats (.wav, .jpg, .png) are fully tagged either
>>> (and some are in my opinion somewhat poorly designed).

>> Your complaint would make sense if the semantics of the .mod were constant
>> over compilers. It isn't. So complaints about poor syntax miss the mark even
>> if they were true.

>> Those with simple semantics will not meet the needs of those that require
>> more complex semantics whatever syntax your might care to have them use.

>> You do not use a VW Beetle to take your sports team across town even if
>> the Beetle is in the team colors. Your complaint is the analogue of asking
>> for the right team colors when there is no chance they will fit inside.

> I was referring specifically to backward compatibility within the same
> compiler system caused by the revision cycle.  However, the above could
> in fact be fully applied across compiler systems if there were a will
> to do so.

The original complaint was about the fact that two different vendors did
not read the .mod files of each other. No issue of revisions involved.

When there are revision issues they will often arise because the new
form contains more information than the old. Otherwise stated, the semantics
have become more complex.



Sun, 22 Aug 2010 10:40:04 GMT  
 Do different compilers produce different .mod files?
Quote:


> It is a real pain to recompile those old CDC6600 object files to run
> on a PC but it is an incompatability that folks have learned to live with.
> I do not recall seeing such a complaint in this newsgroup!

That's true.

However, these days you often don't have to recompile object files from
one compiler in order to use them with another on a PC...except when
they contain modules, because the .mod file is incompatible. Which is
annoying.

I think COFF has spoilt us.

Catherine.
--
Catherine Rees Lay

Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57



Sun, 22 Aug 2010 18:17:30 GMT  
 Do different compilers produce different .mod files?

Thanks all for the replies.
I guess i'll just have to compile the hdf5 library from source.

Jez



Sun, 22 Aug 2010 18:40:27 GMT  
 Do different compilers produce different .mod files?
On 2008-03-05 06:17:30 -0400, Catherine Rees Lay

Quote:


>> It is a real pain to recompile those old CDC6600 object files to run
>> on a PC but it is an incompatability that folks have learned to live with.
>> I do not recall seeing such a complaint in this newsgroup!

> That's true.

> However, these days you often don't have to recompile object files from
> one compiler in order to use them with another on a PC...except when
> they contain modules, because the .mod file is incompatible. Which is
> annoying.

> I think COFF has spoilt us.

> Catherine.

The problems are of two types:

1. Different processors are still incomatible even if they both have
   Unix ports but not everything is Unix. For instance I have both a PPC
   and an X86 "on" my desk. And at least three operating systems. And an
   even larger count of Fortran compilers.

2. I/O libraries are rarely compatible so there can be no I/O if
   using alternate compiler vendors on the same processor/op sys. Many
   commercial library vendors list the several compilers they support and
   require separate licenses for each compiler.

Compared to these the issue of .mod files gets "lost in the roundoff".



Sun, 22 Aug 2010 21:25:05 GMT  
 Do different compilers produce different .mod files?
Quote:






>>>>> said:

>>>> <snip>

>>>>>> Such incompatibilities usually imply to me less than ideal design of
>>>>>> the .mod file structure.  There's almost never good justification for
>>>>>> such incompatibilities.  It is sometimes due to laziness, for example
>>>>>> creating the file structure as a sequence of structures with no
>>>>>> tagging/markup whatsoever.  A tiny bit of thought, such as tagging
>>>>>> (e.g. escape sequences but a little more sophisticated), can avoid
>>>>>> all
>>>>>> incompatibilities, and with minimal I/O performance impact (slightly
>>>>>> more difficult to process tho).

>>>>> The information that a compiler wants to obtain from a USE statement
>>>>> could be as little as some symbols with a small of amount of
>>>>> additional
>>>>> information or as much as the full source of the module. There is no
>>>>> single design that could meet such varying objectives. The Fortran
>>>>> specification does not say what is there and the actual contents would
>>>>> depend upon how agressive the compiler implementors choose to be in
>>>>> being able to analyse the whole program. Those with minor requirements
>>>>> would certainly object to servicing the needs of those with much more
>>>>> extensive requirements.

>>>>> If one were running a Fortran interpreter the USE statement would want
>>>>> the full source (or functional equivalent) to allow the current
>>>>> program
>>>>> to be interpreted.

>>>>> It is a real pain to recompile those old CDC6600 object files to run
>>>>> on a PC but it is an incompatability that folks have learned to
>>>>> live with.

>>>>> I do not recall seeing such a complaint in this newsgroup!

>>>> <snip>

>>>> File format designs that I'm familiar with, tag every single piece of
>>>> data and potentially include version information.  It doesnt' really
>>>> matter if the data itself needed by the compiler is simple or
>>>> complex.  If every piece of data is properly tagged, it can always be
>>>> processed as originally intended.  Object files are not examples of
>>>> fully tagged data.  Nor is any file that assumes particular content by
>>>> mere position of the data within a file or within a record.  Few of
>>>> today's common file formats (.wav, .jpg, .png) are fully tagged either
>>>> (and some are in my opinion somewhat poorly designed).

>>> Your complaint would make sense if the semantics of the .mod were
>>> constant
>>> over compilers. It isn't. So complaints about poor syntax miss the
>>> mark even
>>> if they were true.

>>> Those with simple semantics will not meet the needs of those that
>>> require
>>> more complex semantics whatever syntax your might care to have them use.

>>> You do not use a VW Beetle to take your sports team across town even if
>>> the Beetle is in the team colors. Your complaint is the analogue of
>>> asking
>>> for the right team colors when there is no chance they will fit inside.

>> I was referring specifically to backward compatibility within the same
>> compiler system caused by the revision cycle.  However, the above
>> could in fact be fully applied across compiler systems if there were a
>> will to do so.

> The original complaint was about the fact that two different vendors did
> not read the .mod files of each other. No issue of revisions involved.

> When there are revision issues they will often arise because the new
> form contains more information than the old. Otherwise stated, the
> semantics
> have become more complex.

I was commenting to Richard Maine's comment about incompatibilities
between different versions of the same compiler, not to the original
complaint.

--

Gary Scott

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford



Sun, 22 Aug 2010 21:29:23 GMT  
 Do different compilers produce different .mod files?


Quote:

> Thanks all for the replies.
> I guess i'll just have to compile the hdf5 library from source.

> Jez

What does that entail?

--
Gerry Ford

"Er hat sich georgiert."  Der Spiegel, 2008, sich auf Chimpy Eins komma null
beziehend.



Mon, 23 Aug 2010 09:55:32 GMT  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Salford95 and Lahey-Fujitsu Compiler producing different output with same program

2. different compilers different results?

3. same code run in ifort and f77 produced different file size

4. File mod times different during DST on NT?

5. File mod times different during DST?

6. Call different files in different folder

7. Expect: How to log different process to different files

8. pickle and cPickle produce different results

9. File Format Compatibility between different compilers

10. One object that needs to look different to different senders

11. Different window sizes in different sceen resolutions

12. Different printouts on different printers ?

 

 
Powered by phpBB® Forum Software