On 2011-11-07 09:03+0100 Arjen Markus wrote: > Hi Alan, Maurice, > > On 2011-11-07 03:40, Alan W. Irwin wrote: >> >> Note if we do decide to drop support for the g77 compiler, providing a >> soft landing only requires a tiny modification to our build system. Right >> now we test if the Fortran compiler provides support for Fortran >> 95, and we set ENABLE_f95 to OFF for the case where there is no such >> support. But as far as I know g77 is the only Fortran compiler left >> that provides Fortran 77 support but no Fortran 95 support so all we >> have to do is set ENABLE_f77 to OFF whenever Fortran 95 is not >> supported to make sure the g77 compiler is never used. >> > > g77 has not been maintained for many a year now and it is indeed the > only popular FORTRAN 77-only compiler still in wide enough use. > > I would like to distinguish the single versus double underscore issue > for internal routine names, as I am not at all sure that that scheme > is not used by some other compilers.
To review the history here, this "*.a" workaround started with a commit I made in 2003 (revision 5044) as modified soon after by revision 5137. >From the code comment in bindings/f77/plstubs.h // N.B. By default the g77 compiler appends second underscore to name if // the original name contains any underscore at all. According to info // g77, "This is done to ensure compatibility with code produced by many // UNIX Fortran compilers." However, other fortran compilers do not have // this default naming scheme so to avoid trouble I have #defined two // variations of the embedded underscore names, one with and one without // the extra trailing underscore. So that appears to be a direct quote from "info g77" with no further information about what exactly is meant by "many". That statement does introduce some fear about removing support for this style of name mangling, but both "info gfortran" and the Wikipedia article on name mangling imply the only important use of this scheme is with g77 and f2c (f2c is even older than g77, and does not compile Fortran 95 so it would also be dropped by the above proposed soft landing.) So I am still not sure whether this name mangling scheme is used outside of g77 and f2c, but if so I think it is only relevant to a small fraction of our users. Therefore, I would prefer to deal with the issue is a less intrusive way by defining another STUB_LINKAGE to handle this specific case. I am thinking along the following lines: #elif STUB_LINKAGE == STUB_G77_LAU #define FNAME( x, y ) strchr(y,'_') ? PLDLLIMPEXP_F77C y ## __ : PLDLLIMPEXP_F77C y ## _ #define FNAME_( x, y ) strchr(y,'_') ? ## __ : ## _ I would appreciate technical review of the above idea from those who know more about the limitations of macros than I do. If this idea is technically feasible then it would give a straightforward alternative for those of our users who use Fortran compilers which by default append a double underscore if there is an embedded underscore in the name. The principal advantage of the above method is it allows us to get rid of the "*a" workaround variants that are currently messing up our code. > > Therefore: let us proceed with such a soft landing as Alan describes. > I will hold off on this decision (which is orthogonal to the name mangling decision) until Maurice gets back to us with his response to my gfortran questions. If we decide to keep supporting g77 for now, then we could #define STUB_LINKAGE STUB_G77_LAU in that case (where I think the predefined __G77__ macro would be true although I would need confirmation of that from Maurice). Otherwise, I would simply let individual users who need that name mangling scheme to define that macro with the appropriate -D compile option. 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
