Hi, I made now the changes to the driver source and header for Linux and activated the hidden flag in plplot.h
#pragma GCC visibility push(hidden) and plplot and examples compiles and works for me. Don't know if it should work anyway or not. So we need now to test the changes for the various settings, since I didn't turn on many drivers for that case and also many bindings are missing, so I'm sure there is still a lot to do. Regards, Werner On 10.10.2008, at 08:44, Werner Smekal wrote: > Hi, > > I just admitted lot of changes to get this import/export issue right. > What I basically did I explain in pldll.h: > > #ifndef __PL_DLL_H > #define __PL_DLL_H > > ************************************************************************ > This is now different. We only get into this part of the header > file, if > USINGDLL is defined. This macro must be defined if a static library is > built or used. Depending on the compiler PLDLLEXPORT and PLDLLIMPORT > are > correctly defined. These macros should not be used in source or header > files. > ************************************************************************ > > #ifdef USINGDLL > #if defined(WIN32) > /* Visual C/C++, Borland, MinGW and Watcom */ > #if defined(__VISUALC__) || defined(_MSC_VER) || > defined(__BORLANDC__) || defined(__GNUC__) || defined(__WATCOMC__) > #define PLDLLEXPORT __declspec(dllexport) > #define PLDLLIMPORT __declspec(dllimport) > #else > #define PLDLLEXPORT > #define PLDLLIMPORT > #endif > #elif defined(__CYGWIN__) > #define PLDLLEXPORT __declspec(dllexport) > #define PLDLLIMPORT __declspec(dllimport) > #elif defined(__GNUC__) && __GNUC__ > 3 > /* Follow ideas in http://gcc.gnu.org/wiki/Visibility for GCC > version 4.x > * The following forces exported symbols specifically designated > with > * PLDLLEXPORT to be visible. */ > #define PLDLLEXPORT __attribute__ ((visibility("default"))) > #define PLDLLIMPORT > #endif > #endif > > ************************************************************************ > If USINGDLL was not defined (static library) or for an unknown > compiler > we clear the PLDLLEXPORT/PLDLLIMPORT macros. > ************************************************************************ > > /* For an unknown compiler or static built we clear the macros */ > #ifndef PLDLLEXPORT > #define PLDLLEXPORT > #define PLDLLIMPORT > #endif > > > ************************************************************************ > So for every single shared library we have we set corresponding > macros, > e.g. for the c++ bindings PLDLLIMPEXP_CXX. If this library is just > built, cmake sets the plplotcxxd_EXPORTS macro - in this case we use > the > PLDLLEXPORT macro. If the plplotcxxd_EXPORTS macro is not defined, we > use the library (or not at all) and we use the PLDLLIMPORT macro. In > my > opinion this should get all the correct imports/exports right (if you > use the correct macro in your source and header files). > ************************************************************************ > > /* The IMPEXP macros will always be set to DLLIMPORT (even for > the static library, but DLLIMPORT is empty in this case), if > cmake didn't set the corresponding macro xxxx_EXPORTS when the > corresponding library is built (DLLIMPEXP is set to DLLEXPORT > then) */ > #if defined(plplotd_EXPORTS) > #define PLDLLIMPEXP PLDLLEXPORT > #define PLDLLIMPEXP_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP PLDLLIMPORT > #define PLDLLIMPEXP_DATA(type) PLDLLIMPORT type > #endif > > #if defined(plplotcxxd_EXPORTS) > #define PLDLLIMPEXP_CXX PLDLLEXPORT > #define PLDLLIMPEXP_CXX_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP_CXX PLDLLIMPORT > #define PLDLLIMPEXP_CXX_DATA(type) PLDLLIMPORT type > #endif > > #if defined(plplotf77d_EXPORTS) > #define PLDLLIMPEXP_F77 PLDLLEXPORT > #define PLDLLIMPEXP_F77_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP_F77 PLDLLIMPORT > #define PLDLLIMPEXP_F77_DATA(type) PLDLLIMPORT type > #endif > > #if defined(plplotf95d_EXPORTS) > #define PLDLLIMPEXP_F95 PLDLLEXPORT > #define PLDLLIMPEXP_F95_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP_F95 PLDLLIMPORT > #define PLDLLIMPEXP_F95_DATA(type) PLDLLIMPORT type > #endif > > #if defined(plplotwxwidgetsd_EXPORTS) > #define PLDLLIMPEXP_WX PLDLLEXPORT > #define PLDLLIMPEXP_WX_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP_WX PLDLLIMPORT > #define PLDLLIMPEXP_WX_DATA(type) PLDLLIMPORT type > #endif > > #endif /* __PL_DLL_H */ > > ************************************************************************ > > This works for me now for Win32, C and C++. I switch now to Linux to > see > if it still works :). If not I have to revert a lot of files ;). > Things > left to do are now the shared drivers. I hope that cmake also sets a > export macro for this case, but here we defined only one import/export > macro for all drivers, since the drivers don't depend on each other, > > e.g. > #if defined(svg_EXPORTS) && defined(ps_EXPORTS) ..... > #define PLDLLIMPEXP_DRIVER PLDLLEXPORT > #define PLDLLIMPEXP_DRIVER_DATA(type) PLDLLEXPORT type > #else > #define PLDLLIMPEXP_DRIVER PLDLLIMPORT > #define PLDLLIMPEXP_DRIVER_DATA(type) PLDLLIMPORT type > #endif > > Let's see if this works. > > Regards, > Werner > > Alan W. Irwin wrote: >> 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 > > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: [EMAIL PROTECTED] > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office) > +43-(0)1-58801-13469 (laboratory) > fax: +43-(0)1-58801-13499 > > ------------------------------------------------------------------------- > 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 -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------- 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
