Hi Arjen: Below I discuss our support for the g77 compiler. This should not be confused with our support of bindings/f77 which has been recently discussed. Those bindings currently can be compiled either with the g77 compiler or the gfortran compiler.
I have to deal with fortran name mangling issues in another project (ephcom2) which has underscores in the function name body. So I just reviewed that same issue for PLplot, and I thought it would be good to summarize what I found since our code is somewhat obfuscated. http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_Fortran documents that g77 name mangling has two trailing underscores if there is an underscore in the body of the function name, but gfortran only has one trailing underscore for this case just like most other fortran compilers. To deal with these two different name mangling cases we currently implement two identical functions (except one has an extra trailing underscore). For example, we use the two separate macros #define PL_SETCONTLABELPARAM FNAME( PL_SETCONTLABELPARAM, pl_setcontlabelparam ) #define PL_SETCONTLABELPARAMa FNAME( PL_SETCONTLABELPARAM_, pl_setcontlabelparam_ ) and implement PL_SETCONTLABELPARAM and PL_SETCONTLABELPARAMa identically in the C source code (except for their names). So the g77 compiler uses one of those and the gfortran compiler the other. This occurs for each one of our function names that has an underscore in the body. I don't bother with the "*a" variants for the ephcom2 case since I don't attempt to support the g77 compiler for that case. I have confirmed (with nm, ldd, and run-time tests) that ordinary name mangling without the "*.a" variants works quite well for function names with embedded underscores this morning confirming the above documentation of gfortran name mangling. I think it is important to continually weed unneeded kruft from PLplot to make the codebase as simple to understand as possible. So are the above "*a" variants good candidates for such weeding? That is certainly the case for bindings/f95 since that cannot be compiled by the g77 compiler at all so the "*a" variants there (which apparently were just copied from bindings/f77) are never used. For bindings/f77 that question does not have quite as clear an answer and depends of course, on how long we want to support the g77 compiler which depends on the degree that the g77 compiler is still used by PLplot users. To help with that question, I just checked http://packages.ubuntu.com. It turns out that hardy (8.04LTS) has a g77 package, but lucid (10.04LTS) does not. Furthermore, Canonical no longer supports hardy desktops (although they plan to support hardy servers until April 2013). Does anyone here know the g77 package availability for enterprise RedHat and SuSe? If it turns out the latest released versions of those Linux distributions do not have a g77 compiler (i.e., just like the case for lucid (10.04LTS)) my own inclination would be to drop our g77 compiler support right now in bindings/f77 and always rely instead on gfortran to build that (so long as we continue to support those bindings). g77 compiler support is not relevant to bindings/f95 so the existing "*a" variants there should be dropped immediately. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
