Arjen said: > If I understand the issue of IMPORT/EXPORT correctly, then: > - EXPORT is always necessary to make the function visible > outside the DLL. > - IMPORT is used to tell the linker that the function is coming > from another library, so that it can prepare for a faster call > (otherwise one or two extra instructions are required). > - IMPORT is _not_ needed for a function when that function is > called by another function in the same library - it makes > the call less efficient even. So, IMPORT should go into > the header files exclusively. > > The situation Andrew describes with the dynamic drivers can be > schematised as follows: > > We have functions A and B in the core library and function C > in the driver library. A uses C and C uses B. > > When making the core library: > > EXPORT: A (if it is part of the public interface or used by the bindings) > EXPORT: B (because it is needed - at least - by the driver) > IMPORT: C (as it is used by A) > > When making the driver library: > > EXPORT: C (part of the "public" interface of the driver) > IMPORT: B (C needs to call it) > > If this schema is complete and I read the sources (and especially > the header files) correctly, then we do have an issue with the > IMPORT part: > > When compiling the driver library: > > #include "plplotP.h" <-- PLDLLIMPEXP is defined and so are the > import/export attributes for A and B > from the core library. So, as we are > compiling a DLL: the attribute is EXPORT > #include "drivers.h" <-- defines the atttribute for C to be > PLDLLIMPEXP and therefore EXPORT > > It would seem necessary to have a setup in the driver library as: > > #define USINGDLL > #include "plplotP.h" <-- IMPORT: A, B (only B needed) > #undef USINGDLL > #define MAKINGDLL > #include "pldll.h" > #include "drivers.h" <-- EXPORT: C > > and in the core: > > #define USINGDLL > #include "pldll.h" > #include "drivers.h" <-- IMPORT: C > #define MAKINGDLL > #include "plplotP.h" <-- EXPORT: A, B > > Please examine this carefully, because it is fairly complicated > and the IMPORT attribute has only a subtle effect (that is: it > affects the performance, getting it wrong will not cause a > compile or link error!).
I suggest you simplify the above logic by separating the driver namespace from the core library one just as we currently do for the csa and nn libraries. What I had in mind was using MAKINGDRDLL, USINGDRDLL, DRDLLEXPORT, DRDLLIMPORT, and DRDLLIMPEXP for the driver-related symbols with MAKINGPLDLL, USINGPLDLL, PLDLLEXPORT, PLDLLIMPORT, and PLDLLIMPEXP strictly reserved for the core library symbols. If you follow my suggestion, I don't think you will have to change the order of #includes or change from USING to MAKING in mid-stream like you suggest above. Instead, for the dynamic device case (ENABLE_DYNDRIVERS=ON) build libplplotd with -DMAKINGPLDLL -DUSINGCSADLL -DUSINGNNDLL -DUSINGDRDLL, and build the dynamic devices with -DMAKINGDRDLL -DUSINGPLDLL. This way of doing things is only a small conceptual departure from what we do now (USING and MAKING controlled by CMake, xxxDLLIMPEXP used in the headers and defined as import or export depending on whether USING or MAKING). The only real difference from what we have now in my proposal is the driver/library namespace separation issues are dealt with properly. I should also mention that separating the driver namespace from the core library one is also important for the (usual Windows) case where dynamic loading of drivers is disabled (ENABLE_DYNDRIVERS=OFF). In this case, the device driver code is put into libplplotd so import/export of library and driver code with each other is no longer relevant. Instead, we want to hide all driver symbols from the external world in this case. That is easily arranged by setting DRDLLIMPEXP to nothing while setting PLDLLIMPEXP to the appropriate value. 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
