On 2010-08-13 10:04+0200 Arjen Markus wrote: > Further observations: > Intel Fortran uses the "cdecl" calling convention, not stdcall. This > is not yet reflected in the selection of the STUB_LINKAGE macro (that > currently only depends on the C compiler!) so this is something I need > to adjust. It also means that we have to accommodate for different > link names in a third variety of .def files. > > This is just a consequence of the software evolution on Windows ...
To Arjen and Werner: Is the calling convention also going to be an issue for our visibility support? Right now (in include/pldll.h(.in) we use #define PLDLLEXPORT __declspec( dllexport ) for both non-Cygwin and Cygwin windows. But I have noticed that for the libharu symbol visibility support (see cmake/external/libharu/include/hpdf.h) they use #ifdef HPDF_DLL_MAKE # define HPDF_EXPORT(A) __declspec(dllexport) A __stdcall #else # ifdef HPDF_DLL_MAKE_CDECL # define HPDF_EXPORT(A) __declspec(dllexport) A [...] where "A" is the function type and HPDF_DLL_MAKE_CDECL is defined in the Cygwin case and HPDF_DLL_MAKE defined in the non-Cygwin Windows case. Note, I don't understand Windows symbol visibility syntax at all, but the implication from the name of the macro in the Cygwin case and the use of __stdcall in the non-Cygwin Windows case is that Cygwin uses the "cdecl" calling convention (whatever that is) and non-Cygwin Windows uses "stdcall" calling convention (whatever that is). In sum, it appears the libharu developers were unaware of the cdecl calling convention for the Intel compiler, but they do appear to distinguish the two calling conventions in their visibility support so we might want to consider doing that ourselves (by adding the __stdcall attribute for the stdcall case). Even more importantly, if Cygwin really does use the cdecl calling convention it appears from Arjen's comments above there would be widespread Cygwin fortran implications (which may explain why fortran has historically been problematic for PLplot on Cygwin). I am out of my depth so I am just mentioning some possibilities here based on what libharu does to give you guys some food for thought. 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 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 __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
