fortran, Do different compilers produce different .mod files?

Do different compilers produce different .mod files?

Author	Message
bonza.. #1 / 24	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

Richard Mai #2 / 24	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

GaryScot #3 / 24	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). - Hide quoted text - - 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

relaxmik #4 / 24	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

Gordon Sand #5 / 24	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! - Hide quoted text - - 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

Paul van Dels #6 / 24	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

GaryScot #7 / 24	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

Gordon Sand #8 / 24	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

Gary Scot #9 / 24	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

Gordon Sand #10 / 24	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

Catherine Rees La #11 / 24	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

bonza.. #12 / 24	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

Gordon Sand #13 / 24	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

Gary Scot #14 / 24	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

Gerry For #15 / 24	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

Page 1 of 2

[ 24 post ]

Go to page: [1] [2]