From: Alan W. I. <ir...@be...> - 2006-05-17 18:57:11
|
On 2006-05-17 09:08-0500 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > On 2006-05-17 02:20-0400 Jim Dishaw wrote: > > > [...] > > > > You are the first who has expressed a strong opinion on this so I will try > > to pay attention to your views, but I do need some clarification of your > > arguments, especially the motivation for the compiler-dependent part. > > I've been out of the Fortran business for a while (phwew!), but I think I > remember this well enough to explain just a bit. > > Module files are essentially a compilation product. Users write modules (by > which I mean, module definitions), but the Fortran source that defines a > module is "compiled" into a module file. This file is conceptually similar > to a .o, or perhaps even more akin to a precompiled header repo in the C/C++ > world. From what I can see from the ascii output of the *.mod files generated by gfortran it is more akin to the latter. It looks like the file collects information about argument list typing and predefined constants similar to the information collected in a C header. That is, it defines at least the API of the fortran library. (There may be other information carried by module files as well that I am unaware of.) However, the analogy is not perfect; C headers use C syntax while gfortran modules although written in ascii do not use fortran syntax. > As such, it's contents are compiler specific. There is no reason to > expect that one compiled module file from one Fortran compiler, would be > usable by another. Understood. One comment made previously on this list is some fortran compilers actually produce binary module files. UGH, what a nice way to obfuscate API details. > It would be more like a situation with binutils where one > compiler uses ELF and another COFF. The compilation products simply wouldn't > mix. Or, trying to mix precompiled header repos between GCC and some vendor > compiler. Just doesn't work that way. Fortran 9x modules are like that. At > least, that's my understanding. > > The mix-and-match thing within a single prefix, seems off to me, though. As > I've described seperately previously, we have to keep our toolchains distinct > for different C++ compilers, due to linkage differences. We do this by > mangling an "environment identifier string" into the name of any library (.a > or .so) which contains C++. At our shop, we use only the C interface to > PLplot, so we don't have to take this step with libplplotd.so. But were we > to use any driver that depended on C++, or were PLplot to grow direct use of > C++, such measures would become important. Right now, the only way to deal > with such matters would simply be to build a different prefix for each > toolchain with incompatible linkage considerations. > > Again, the F9X situation seems similar to me. At ths point, PLplot does not > really have a way to mangle in compilation environment disambiguators into > the names of the libraries, not supported by plplot-config, etc. While I can > see an argument for storing PLplot compiled Fortran modules in some way > segregated by compiler vendor name or whatnot, I would point out that if > we're to address this issue in the context of PLplot, it is a lot bigger than > just Fortran. So, from the perspective of maintaining consistency in how we > handle such matters, I think it makes more sense to just say "build a > seperate prefix" to support F9X modules with multiple compilers. > > As a longer term development issue, we could see if we could come up with a > scheme to handle multiple mutually incompatible toolchain environments > within a single prefix. But's a big job, and multiple prefixes are a > workable substitute. Agreed. So since compiler disambiguation does not make sense at the moment, I believe that narrows down the choices to $prefix/share/fortran/modules/plplot (the current setting), or $prefix/lib/fortran/modules/plplot. It's possible that gfortran produces exactly the same module files for different architectures, but I don't know that for sure. Furthermore, it is probable that the commercial compilers might not be so integrated (e.g., module files from their 64-bit version might not be consistent with those from their 32-bit version which might be written by an entirely different team of programmers). Therefore, I plan to change over to the "lib" choice assuming there is at least one compiler that does not have architecture independence for its generated *.mod files. Geoffrey, Arjen and Jim, let me know if you have any strong objections to that move. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |