From: Robert P. <rob...@jk...> - 2008-10-07 16:11:22
|
Hello, I am using Windows XP, the Visual Studio 2008 Express Edition and cmake-2.6.2. I am trying to build the current PLPlot trunk (revision 8861) with the following batch file in the PLPlot root folder: REM start of script echo on setlocal call "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat" set BUILD_TYPE=Debug rmdir /S /Q build-vc9-static-%BUILD_TYPE% mkdir build-vc9-static-%BUILD_TYPE% cd build-vc9-static-%BUILD_TYPE% cmake -G "NMake Makefiles" ^ -DCMAKE_BUILD_TYPE=%BUILD_TYPE% ^ -DCMAKE_INSTALL_PREFIX=install ^ -DBUILD_SHARED_LIBS=OFF ^ -DCMAKE_VERBOSE_MAKEFILE=ON ^ -DBUILD_TEST=ON ^ .. nmake REM end of script This runs up to the following compile error: cl /DWIN32 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -ID:\project\PLPlot\include -ID:\project\PLPlot\build-vc9-static-Debug -ID:\project\PLPlot\build-vc9-static-Debug\include -DHAVE_CONFIG_H -D_CRT_SECURE_NO_DEPRECATE /FoCMakeFiles\plplotd.dir\__\drivers\hpgl.obj /FdD:\project\PLPlot\build-vc9-static-Debug\src\plplotd.pdb -c D:\project\PLPlot\drivers\hpgl.c hpgl.c D:\project\PLPlot\drivers\hpgl.c(141) : error C2375: 'plD_dispatch_init_hp7470': redefinition; different linkage D:\project\PLPlot\include\drivers.h(73) : see declaration of 'plD_dispatch_init_hp7470' When I switch off one affected driver after the other (as with -DPLD_hp7470=OFF), I see the error appearing in a lot of drivers. The same error appears with BUILD_TYPE=Release and with -DBUILD_SHARED_LIBS=ON. I have noticed that people already successfully use PLPlot with msvc9. How do you build? Best regards, Robert Pollak |
From: Alan W. I. <ir...@be...> - 2008-10-07 17:52:37
|
Hi Robert: Thanks for your report for revision 8861, the latest svn trunk version of PLplot. Arjen, I have a question for you below. On 2008-10-07 17:40+0200 Robert Pollak wrote: [...] > cmake -G "NMake Makefiles" ^ > -DCMAKE_BUILD_TYPE=%BUILD_TYPE% ^ > -DCMAKE_INSTALL_PREFIX=install ^ > -DBUILD_SHARED_LIBS=OFF ^ > -DCMAKE_VERBOSE_MAKEFILE=ON ^ > -DBUILD_TEST=ON ^ .. [...] > This runs up to the following compile error: > cl /DWIN32 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 > -ID:\project\PLPlot\include -ID:\project\PLPlot\build-vc9-static-Debug > -ID:\project\PLPlot\build-vc9-static-Debug\include -DHAVE_CONFIG_H > -D_CRT_SECURE_NO_DEPRECATE /FoCMakeFiles\plplotd.dir\__\drivers\hpgl.obj > /FdD:\project\PLPlot\build-vc9-static-Debug\src\plplotd.pdb -c > D:\project\PLPlot\drivers\hpgl.c > > [...]hpgl.c > D:\project\PLPlot\drivers\hpgl.c(141) : error C2375: > 'plD_dispatch_init_hp7470': redefinition; different linkage > D:\project\PLPlot\include\drivers.h(73) : see declaration of > 'plD_dispatch_init_hp7470' > > > When I switch off one affected driver after the other (as with > -DPLD_hp7470=OFF), I see the error appearing in a lot of drivers. Arjen, you are the PLplot expert in this area so this question is directed to you: The two lines in question are drivers/hpgl.c, line 140 PLDLLEXPORT void plD_dispatch_init_hp7470( PLDispatchTable *pdt ) and include/drivers.h, line 73 PLDLLIMPEXP void plD_dispatch_init_hp7470 ( PLDispatchTable *pdt ); So I believe this user found a combination of flags that set PLDLLIMPEXP different from PLDLLEXPORT. The relevant logic is in include/pldll.h #if defined(MAKINGPLDLL) #define PLDLLIMPEXP PLDLLEXPORT #define PLDLLIMPEXP_DATA(type) PLDLLEXPORT type #elif defined(USINGPLDLL) #define PLDLLIMPEXP PLDLLIMPORT #define PLDLLIMPEXP_DATA(type) PLDLLIMPORT type #else #define PLDLLIMPEXP #define PLDLLIMPEXP_DATA(type) type #endif I think the key to this issue is this user specified the cmake option -DBUILD_SHARED_LIBS=OFF which means MAKINGPLDLL is not defined, in which case PLDLLIMPEXP is defined to nothing, but PLDLLEXPORT is still defined to something (by the Windows stanzas earlier in include/pldll.h). Robert, what happens if you add #define PLDLLEXPORT #define PLDLLIMPORT to the #else stanza above? I predict that will fix your problem with the -DBUILD_SHARED_LIBS=OFF case. Arjen, if you agree that is no-brainer fix, please make the commit. (I feel intimidated from doing that myself because I have no access to windows boxes to even make a superficial test of the change.) 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 __________________________ |
From: Arjen M. <arj...@wl...> - 2008-10-08 06:58:14
|
Alan W. Irwin wrote: > Hi Robert: > > Thanks for your report for revision 8861, the latest svn trunk version > of PLplot. > > Arjen, I have a question for you below. > > On 2008-10-07 17:40+0200 Robert Pollak wrote: > > > [...] > >> cmake -G "NMake Makefiles" ^ >> -DCMAKE_BUILD_TYPE=%BUILD_TYPE% ^ >> -DCMAKE_INSTALL_PREFIX=install ^ >> -DBUILD_SHARED_LIBS=OFF ^ >> -DCMAKE_VERBOSE_MAKEFILE=ON ^ >> -DBUILD_TEST=ON ^ > > .. > [...] > >> This runs up to the following compile error: > > >> cl /DWIN32 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 >> -ID:\project\PLPlot\include -ID:\project\PLPlot\build-vc9-static-Debug >> -ID:\project\PLPlot\build-vc9-static-Debug\include -DHAVE_CONFIG_H >> -D_CRT_SECURE_NO_DEPRECATE /FoCMakeFiles\plplotd.dir\__\drivers\hpgl.obj >> /FdD:\project\PLPlot\build-vc9-static-Debug\src\plplotd.pdb -c >> D:\project\PLPlot\drivers\hpgl.c >> >> [...]hpgl.c >> D:\project\PLPlot\drivers\hpgl.c(141) : error C2375: >> 'plD_dispatch_init_hp7470': redefinition; different linkage >> D:\project\PLPlot\include\drivers.h(73) : see declaration of >> 'plD_dispatch_init_hp7470' >> >> >> When I switch off one affected driver after the other (as with >> -DPLD_hp7470=OFF), I see the error appearing in a lot of drivers. > > > Arjen, you are the PLplot expert in this area so this question is > directed to you: > > The two lines in question are > > drivers/hpgl.c, line 140 > > PLDLLEXPORT void plD_dispatch_init_hp7470( PLDispatchTable *pdt ) > > and > > include/drivers.h, line 73 > > PLDLLIMPEXP void plD_dispatch_init_hp7470 ( PLDispatchTable *pdt ); > > So I believe this user found a combination of flags that set PLDLLIMPEXP > different from PLDLLEXPORT. > > The relevant logic is in include/pldll.h > > #if defined(MAKINGPLDLL) > #define PLDLLIMPEXP PLDLLEXPORT > #define PLDLLIMPEXP_DATA(type) PLDLLEXPORT type > #elif defined(USINGPLDLL) > #define PLDLLIMPEXP PLDLLIMPORT > #define PLDLLIMPEXP_DATA(type) PLDLLIMPORT type > #else > #define PLDLLIMPEXP > #define PLDLLIMPEXP_DATA(type) type > #endif > > I think the key to this issue is this user specified the cmake option > -DBUILD_SHARED_LIBS=OFF which means MAKINGPLDLL is not defined, in which > case PLDLLIMPEXP is defined to nothing, but PLDLLEXPORT is still defined > to something (by the Windows stanzas earlier in include/pldll.h). > > Robert, what happens if you add > > #define PLDLLEXPORT > #define PLDLLIMPORT > > to the #else stanza above? I predict that will fix your problem with > the -DBUILD_SHARED_LIBS=OFF case. > > Arjen, if you agree that is no-brainer fix, please make the commit. > (I feel > intimidated from doing that myself because I have no access to windows > boxes to even make a superficial test of the change.) Hi Alan, Robert, that would indeed seem to be the right thing to do. Mind you, the static-library option (BUILD_SHARED_LIBS=OFF) is a not too well tested configuration option. You may run into other problems later on, but at least this one should work. I will make the commit asap, if Robert can confirm that this indeed works and there are no further glitches down the line. Otherwise I will have to investigate ;). Regards, Arjen |
From: Robert P. <rob...@jk...> - 2008-10-08 09:38:10
|
Hi Alan, Arjen, Alan wrote: > Robert, what happens if you add > > #define PLDLLEXPORT > #define PLDLLIMPORT > > to the #else stanza above? I predict that will fix your problem with > the -DBUILD_SHARED_LIBS=OFF case. Yes, this fixes the problem in this case (besides some macro redefinition warnings). ( Unfortunately, it makes another compile error in svg.c visible: D:\project\PLPlot\drivers\svg.c(341) : error C2143: syntax error : missing ';' before 'type' I'll take a look at that. ) > I think the key to this issue is this user specified the cmake option > -DBUILD_SHARED_LIBS=OFF [...] A build with BUILD_SHARED_LIBS=ON gets problems at the same location (in unmodified rev8861): cl -Dplplotd_EXPORTS /DWIN32 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -ID:\project\PLPlot\include -ID:\project\PLPlot\build-vc9-shared-Debug -ID:\project\PLPlot\build-vc9-shared-Debug\include -DHAVE_CONFIG_H -D_CRT_SECURE_NO_DEPRECATE /FoCMakeFiles\plplotd.dir\__\drivers\hpgl.obj /FdD:\project\PLPlot \build-vc9-shared-Debug\dll\plplotd.pdb -c D:\project\PLPlot\drivers\hpgl.c hpgl.c D:\project\PLPlot\drivers\hpgl.c(141) : error C2375: 'plD_dispatch_init_hp7470': redefinition; different linkage D:\project\PLPlot\include\drivers.h(73) : see declaration of 'plD_dispatch_init_hp7470' Adding the snippet #define STRINGIZE2(x) #x #define STRINGIZE(x) STRINGIZE2(x) #pragma message ("PLDLLEXPORT" STRINGIZE(: PLDLLEXPORT)) #pragma message ("PLDLLIMPEXP" STRINGIZE(: PLDLLIMPEXP)) to hpgl.c (in otherwise unmodified rev8861) shows that for BUILD_SHARED_LIBS=ON PLDLLEXPORT expands to __declspec(dllexport), but PLDLLIMPEXP stays empty. Further investigation shows that MAKINGPLDLL is not defined when compiling hpgl.c. -- Robert |
From: Alan W. I. <ir...@be...> - 2008-10-08 18:16:21
|
On 2008-10-08 11:31+0200 Robert Pollak wrote: > Hi Alan, Arjen, > > Alan wrote: >> Robert, what happens if you add >> >> #define PLDLLEXPORT >> #define PLDLLIMPORT >> >> to the #else stanza above? I predict that will fix your problem with >> the -DBUILD_SHARED_LIBS=OFF case. > > Yes, this fixes the problem in this case (besides some macro > redefinition warnings). I have made the change (also for lib/csa/csaldd.h and lib/nn/nnldd.h) as of revision 8864. Arjen, could you please implement a more elegant way to do this to get rid of all the extra compilation warnings due to the macro redefinitions in the present implementation? 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 __________________________ |
From: Arjen M. <arj...@wl...> - 2008-10-09 07:02:34
|
Alan W. Irwin wrote: > On 2008-10-08 11:31+0200 Robert Pollak wrote: > >> Hi Alan, Arjen, >> >> Alan wrote: >> >>> Robert, what happens if you add >>> >>> #define PLDLLEXPORT >>> #define PLDLLIMPORT >>> >>> to the #else stanza above? I predict that will fix your problem with >>> the -DBUILD_SHARED_LIBS=OFF case. >> >> >> Yes, this fixes the problem in this case (besides some macro >> redefinition warnings). > > > I have made the change (also for lib/csa/csaldd.h and lib/nn/nnldd.h) > as of > revision 8864. > > Arjen, could you please implement a more elegant way to do this to get > rid > of all the extra compilation warnings due to the macro redefinitions > in the > present implementation? > Hi Alan, sure, I should have time this evening - in the worst case, a #undef should do the trick. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2008-10-09 14:43:09
|
Hi, sorry, that I (again) kick in late in this discussion, but this change was not the right solution. Actually, the macros PLDLLEXPORT/ PLDLLIMPORT are not to be used outside pldll.h. Only PLDLLIMPEXP should be used in headers and source. This was correctly done for the plplot core source, but not for the driver sources. So I changed now all PLDLLEXPORT macros to PLDLLIMPEXP and ask anybody if he needs to use this macros only to use PLDLLIMPEXP or NNDLLIMPEXP ... Will commit that soon. Regards, Werner On 08.10.2008, at 20:16, Alan W. Irwin wrote: > On 2008-10-08 11:31+0200 Robert Pollak wrote: > >> Hi Alan, Arjen, >> >> Alan wrote: >>> Robert, what happens if you add >>> >>> #define PLDLLEXPORT >>> #define PLDLLIMPORT >>> >>> to the #else stanza above? I predict that will fix your problem >>> with >>> the -DBUILD_SHARED_LIBS=OFF case. >> >> Yes, this fixes the problem in this case (besides some macro >> redefinition warnings). > > I have made the change (also for lib/csa/csaldd.h and lib/nn/ > nnldd.h) as of > revision 8864. > > Arjen, could you please implement a more elegant way to do this to > get rid > of all the extra compilation warnings due to the macro redefinitions > in the > present implementation? > > 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 > Plp...@li... > 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: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2008-10-09 15:44:40
|
On 2008-10-09 16:42+0200 Werner Smekal wrote: > Hi, > > sorry, that I (again) kick in late in this discussion, but this change was > not the right solution. Actually, the macros PLDLLEXPORT/PLDLLIMPORT are not > to be used outside pldll.h. Only PLDLLIMPEXP should be used in headers and > source. This was correctly done for the plplot core source, but not for the > driver sources. So I changed now all PLDLLEXPORT macros to PLDLLIMPEXP and > ask anybody if he needs to use this macros only to use PLDLLIMPEXP or > NNDLLIMPEXP ... > > Will commit that soon. Thanks, Werner, for looking deeper into this issue and solving the problem at a more fundamental level. 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 __________________________ |
From: Andrew R. <and...@us...> - 2008-10-09 17:30:33
|
On Thu, Oct 09, 2008 at 08:44:34AM -0700, Alan Irwin wrote: > On 2008-10-09 16:42+0200 Werner Smekal wrote: > > > Hi, > > > > sorry, that I (again) kick in late in this discussion, but this change was > > not the right solution. Actually, the macros PLDLLEXPORT/PLDLLIMPORT are not > > to be used outside pldll.h. Only PLDLLIMPEXP should be used in headers and > > source. This was correctly done for the plplot core source, but not for the > > driver sources. So I changed now all PLDLLEXPORT macros to PLDLLIMPEXP and > > ask anybody if he needs to use this macros only to use PLDLLIMPEXP or > > NNDLLIMPEXP ... > > > > Will commit that soon. > > Thanks, Werner, for looking deeper into this issue and solving the problem > at a more fundamental level. This may not be quite the right long term solution. Language bindings for example might be importing some symbols from the core library and exporting others to the user. Similarly for drivers. I'm not quite sure why things work at the moment. I suspect it is because the import is optional. We should probably try to fix this though to make it really clear whether we are importing or exporting. I did this for the drivers - they use PLDLLEXPORT in the source because they only every export symbols to the core library. The imports are defined elsewhere. Andrew |
From: Werner S. <sm...@ia...> - 2008-10-09 19:10:06
|
Hi Andrew, > This may not be quite the right long term solution. Language bindings > for example might be importing some symbols from the core library and > exporting others to the user. Similarly for drivers. Sure. Ok, I rephrase: this is the correct solution as it was initially considered, but since plplot is a little more complicated, we need to adjust that (in the long term). > > I'm not quite sure why things work at the moment. I suspect it is > because the import is optional. We should probably try to fix this > though to make it really clear whether we are importing or exporting. > > I did this for the drivers - they use PLDLLEXPORT in the source because > they only every export symbols to the core library. The imports are > defined elsewhere. This is something, what should be decided by the cmake and not by the source/headers files. So if xxxMAKINGDLL is defined, xxxIMPEXP is defined to export symbols, if USINGDLL is defined, xxxIMPEXP is defined to import symbols. For the core library its easy, we always export (still we should use DLLIMPEXP). For the examples it's also easy we always import. For the bindings, it's more complicated since we export symbols, but also import symbols from the core. Drivers are also a different story. I suggest that we use the macro cmake defines at compile time for shared libraries. if you run "make VERBOSE=1" for the shared libraries you will see that a macro like "-Dplplotd_EXPORT" is defined. So we always know, what is built in the moment, and set DLLEXPIMP to export. I hope that this will also be set for the drivers. We then don't have to worry about defining MAKINGDLL at the correct time. This is something we have to investigate further. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Andrew R. <and...@us...> - 2008-10-09 19:39:54
|
On Thu, Oct 09, 2008 at 09:09:47PM +0200, Werner Smekal wrote: > Hi Andrew, > > > > This may not be quite the right long term solution. Language bindings > > for example might be importing some symbols from the core library and > > exporting others to the user. Similarly for drivers. > > Sure. Ok, I rephrase: this is the correct solution as it was initially > considered, but since plplot is a little more complicated, we need to > adjust that (in the long term). > > > > I'm not quite sure why things work at the moment. I suspect it is > > because the import is optional. We should probably try to fix this > > though to make it really clear whether we are importing or exporting. > > > > I did this for the drivers - they use PLDLLEXPORT in the source because > > they only every export symbols to the core library. The imports are > > defined elsewhere. > > This is something, what should be decided by the cmake and not by the > source/headers files. So if xxxMAKINGDLL is defined, xxxIMPEXP is > defined to export symbols, if USINGDLL is defined, xxxIMPEXP is defined > to import symbols. For the core library its easy, we always export > (still we should use DLLIMPEXP). For the examples it's also easy we > always import. For the bindings, it's more complicated since we export > symbols, but also import symbols from the core. Drivers are also a > different story. > > I suggest that we use the macro cmake defines at compile time for shared > libraries. if you run "make VERBOSE=1" for the shared libraries you will > see that a macro like "-Dplplotd_EXPORT" is defined. So we always know, > what is built in the moment, and set DLLEXPIMP to export. I hope that > this will also be set for the drivers. We then don't have to worry about > defining MAKINGDLL at the correct time. > > This is something we have to investigate further. It's not quite a cmake issue since we need xxxMAKINGDLL for the driver source file and xxxUSINGDLL for the core header files included by the source file. At the moment these are mutually exclusive so we can't do it with just cmake options. It will require some source code changes as well, or a change to the way we use the defines. So far as I can see we only need DLLEXPIMP for the header files which are used both for making the library and using it. Andrew |
From: Alan W. I. <ir...@be...> - 2008-10-09 22:44:55
|
On 2008-10-09 20:39+0100 Andrew Ross wrote: > It's not quite a cmake issue since we need xxxMAKINGDLL for the driver > source file and xxxUSINGDLL for the core header files included by the > source file. At the moment these are mutually exclusive so we can't do > it with just cmake options. It will require some source code changes > as well, or a change to the way we use the defines. So far as I can see > we only need DLLEXPIMP for the header files which are used both for > making the library and using it. Andrew, could you please explain further? I thought the whole point of DLLEXPIMP was to mean one thing if xxxMAKINGDLL was set by CMake (e.g., in src/CMakeLists.txt to build libplplot), and another if xxxUSINGDLL was set by CMake, e.g., in drivers/CMakeLists.txt when building dynamic devices. So I thought all was well for the dynamic drivers case as changed recently by Werner. It appears from your comment that you have spotted some flaw in that approach. What am I missing? Or are you happy with the current dynamic devices build and thinking about some other build issue? 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 __________________________ |
From: Andrew R. <and...@us...> - 2008-10-10 03:30:02
|
On Thu, Oct 09, 2008 at 03:17:40PM -0700, Alan Irwin wrote: > On 2008-10-09 20:39+0100 Andrew Ross wrote: > > > It's not quite a cmake issue since we need xxxMAKINGDLL for the driver > > source file and xxxUSINGDLL for the core header files included by the > > source file. At the moment these are mutually exclusive so we can't do > > it with just cmake options. It will require some source code changes > > as well, or a change to the way we use the defines. So far as I can see > > we only need DLLEXPIMP for the header files which are used both for > > making the library and using it. > > Andrew, could you please explain further? I thought the whole point of > DLLEXPIMP was to mean one thing if xxxMAKINGDLL was set by CMake (e.g., in > src/CMakeLists.txt to build libplplot), and another if xxxUSINGDLL was set > by CMake, e.g., in drivers/CMakeLists.txt when building dynamic devices. So > I thought all was well for the dynamic drivers case as changed recently by > Werner. It appears from your comment that you have spotted some flaw in > that approach. What am I missing? Or are you happy with the current > dynamic devices build and thinking about some other build issue? It is. Setting xxxUSINGDLL for the drivers ensures that all the symbols from the core library defined in plplot.h etc are imported into the driver. This is ok. However, there are some symbols in the driver files which are exported to the core library (mostly the dispatch_init function and DEVICE INFO structure. I think these would need xxxMAKINGDLL defined. Or am I missing something here? Andrew |
From: Arjen M. <arj...@wl...> - 2008-10-10 04:29:15
|
> On Thu, Oct 09, 2008 at 03:17:40PM -0700, Alan Irwin wrote: > It is. Setting xxxUSINGDLL for the drivers ensures that all the > symbols from the core library defined in plplot.h etc are imported into > the driver. This is ok. However, there are some symbols in the driver > files which are exported to the core library (mostly the dispatch_init > function and DEVICE INFO structure. I think these would need > xxxMAKINGDLL defined. Or am I missing something here? > 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!). Regards, Arjen > > |
From: Alan W. I. <ir...@be...> - 2008-10-10 06:21:25
|
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 __________________________ |
From: Arjen M. <arj...@wl...> - 2008-10-10 06:38:28
|
Alan W. Irwin wrote: > > 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. Ah, indeed! That is the way forward. That makes it much easier, at the mere expense of an extra header file and a few macros. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2008-10-10 06:45:03
|
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 > Plp...@li... > 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: sm...@ia... 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 |
From: Werner S. <sm...@ia...> - 2008-10-10 07:32:21
|
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 >> Plp...@li... >> 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: sm...@ia... > 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 > Plp...@li... > 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: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2008-10-10 16:30:25
|
On 2008-10-10 09:32+0200 Werner Smekal wrote: > 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. Werner, I am virtually positive you forgot to commit all your changes. Currently, (revision 8872) I can find no mention of plplotd_EXPORTS in src/CMakeLists.txt. In fact I can find no mention of any of the *EXPORTS macros in any file in our source tree other than pldll.h so they never get #defined, and the logic will obviously not work in its revision 8872 state since every symbol is imported. Since you obviously got it to work in the Windows case and at least partially in the Linux case I conclude you forgot to commit all of your changes. Also, when testing on Linux, Andrew and I found the pragma approach was not reliable. We intend to revisit that idea later (most likely with a different placement of the pragma) so we disabled it rather than removing it. Instead for our visibility testing we set export CC='gcc -fvisibility=hidden' export CXX='g++ -fvisibility=hidden' export FC='gfortran -fvisibility=hidden' before using cmake in an empty build tree. I would be happy to test your work in the Linux case using this approach once all your present work is committed. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2008-10-10 17:42:25
|
Hi Alan, no, I didn't forget to commit the changes. It's actually cmake which defines this xxx_EXPORTS for us. Compile the library in verbose mode make VERBOSE=1 and you will see in the command line that the corresponding xxx_EXPORTS show up. Regards, Werner Alan W. Irwin wrote: > On 2008-10-10 09:32+0200 Werner Smekal wrote: > >> 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. > > Werner, I am virtually positive you forgot to commit all your changes. > Currently, (revision 8872) I can find no mention of plplotd_EXPORTS in > src/CMakeLists.txt. In fact I can find no mention of any of the *EXPORTS > macros in any file in our source tree other than pldll.h so they never get > #defined, and the logic will obviously not work in its revision 8872 state > since every symbol is imported. Since you obviously got it to work in the > Windows case and at least partially in the Linux case I conclude you forgot > to commit all of your changes. > > Also, when testing on Linux, Andrew and I found the pragma approach was not > reliable. We intend to revisit that idea later (most likely with a > different > placement of the pragma) so we disabled it rather than removing it. Instead > for our visibility testing we set > > export CC='gcc -fvisibility=hidden' > export CXX='g++ -fvisibility=hidden' > export FC='gfortran -fvisibility=hidden' > > before using cmake in an empty build tree. > > I would be happy to test your work in the Linux case using this approach > once all your present work is committed. > > 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2008-10-10 18:49:35
|
On 2008-10-10 19:42+0200 Werner Smekal wrote: > Hi Alan, > > no, I didn't forget to commit the changes. It's actually cmake which defines > this xxx_EXPORTS for us. Compile the library in verbose mode > > make VERBOSE=1 > > and you will see in the command line that the corresponding xxx_EXPORTS show > up. Thanks for that clarification. I had no idea that cmake was doing that automatically. I have some reservations about utilizing these automatically produced xxx_EXPORTS (LIB_TAG means pldll.h ultimately has to be configured, and backwards compatibility with our minimum version of cmake-2.4.5 also has to be tested). However, the present system is fine for testing purposes now for at least double precision libraries and CMake-2.6.x. I did such tests using the preferred export CC='gcc -fvisibility=hidden' export CXX='g++ -fvisibility=hidden' export FC='gfortran -fvisibility=hidden' method for Linux which showed a spelling mistake for the C wrapper libraries for both f77 and f95 which I have now fixed (revision 8873). The current Linux visibility status for cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake -DBUILD_TEST=ON -DPLD_wxwidgets=ON -DHAVE_PTHREAD=ON -DENABLE_pdl=ON -DHAVE_ADA_2007=ON -DENABLE_tcl=OFF (i.e., a rather fully loaded configuration other than Tcl which had a visibility issue revealed at build time which I had to avoid) shows no build errors. However, ctest reveals some limited run-time errors for psttc, pscairo, and pngcairo. Note that the fortran examples passed ctest. This was a bit surprising to me since we do something special in the headers to make symbols in the C source code libraries libplplotf77cd and libplplotf95cd visible, but we have no mechanism to do the same thing for the Fortran source code libraries libplplotf77d and libplplotf95d. The only reasonable conclusion is gfortran always exposes all symbols in Fortran source code libraries and the above -fvisibility=hidden option for gfortran is just ignored. Arjen and Werner, that probably means your gfortran ctests will also pass on Windows (for revision 8873). Later today I hope to report visibility fixes for Tcl, psttc, and the cairo device driver, bit meanwhile, many thanks, Werner, for straightening out the general namespace issues with the previous visibility treatment. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-10 22:26:45
|
On 2008-10-10 11:49-0700 Alan W. Irwin wrote: > Later today I hope to report visibility fixes for Tcl, psttc, and the cairo > device driver, bit meanwhile, many thanks, Werner, for straightening out the > general namespace issues with the previous visibility treatment. With my latest changes I think I have complete (at least as far as ctest is concerned) success for Linux visibility testing done with export CC='gcc -fvisibility=hidden' export CXX='g++ -fvisibility=hidden' export FC='gfortran -fvisibility=hidden' As of revision 8879 here is what I get now: 1/ 17 Testing examples_c Passed 2/ 17 Testing examples_cxx Passed 3/ 17 Testing examples_f77 Passed 4/ 17 Testing examples_f95 Passed 5/ 17 Testing examples_java Passed 6/ 17 Testing examples_octave Passed 7/ 17 Testing examples_python Passed 8/ 17 Testing examples_tcl Passed 9/ 17 Testing examples_perl ***Failed 10/ 17 Testing examples_ada Passed 11/ 17 Testing examples_ocaml Passed 12/ 17 Testing examples_psttfc Passed 13/ 17 Testing examples_png Passed 14/ 17 Testing examples_svg Passed 15/ 17 Testing examples_pscairo Passed 16/ 17 Testing examples_pngcairo Passed 17/ 17 Testing examples_compare ***Failed Here are details of the comparison test: c++ Missing examples : Differing examples : f77 Missing examples : Differing examples : f95 Missing examples : Differing examples : java Missing examples : 19 Differing examples : octave Missing examples : 19 Differing examples : python Missing examples : 19 Differing examples : tcl Missing examples : 19 Differing examples : 11 13 15 16 20 perl Missing examples : 21 22 23 24 25 26 27 28 29 30 Differing examples : 02 08 20 ada Missing examples : Differing examples : ocaml Missing examples : Differing examples : The above result is as good as it gets for ctest these days. The perl problem is caused by the external PDL/plplot project that is distributed with Debian testing (version 1:2.4.3-6+b1) being far behind what libplplot provides as an API these days. I don't know if Doug Hunt has addressed this issue yet for later releases of PDL (if any). However, it does seem that until the API issues were encountered for example 20, everything was working reasonably well for perl/pdl in terms of visibility. I am keen on minimalism so for my next PLplot step (later today) I hope to remove all the redundant (I think) macro use in the various device driver source code files since that is dealt with by drivers.h. Also, I may get a chance today to test the case when dynamic devices are disabled. But that case has already been tested on Windows so I may be close to being done with my contribution to visibility testing/debugging on Linux. Now to bring up a different, but related topic. Werner, do you know the Windows library call (or calls) to dynamically load plug-ins? If so, I think basically all you have to do to implement dynamic drivers on Windows is replace the libltdl calls (lt_dlinit, lt_dlopenext, lt_dlsym, and lt_dlexit) in src/plcore.c and drivers/get-drv-info.c by the equivalent Windows library functions for the #if defined(WIN32) case. So long as you know how to dynamically load on Windows, I don't think this will be a particularly time-consuming project, and it really is time for the Windows version of PLplot to get access to this nice feature that all the Unix developers and users enjoy. If you do decide to attempt to make dynamic devices available on Windows, then I believe from my tests today that you are unlikely to encounter any Windows import/export/visibility issues for those devices. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-11 06:33:41
|
On 2008-10-10 15:26-0700 Alan W. Irwin wrote: > I am keen on minimalism so for my next PLplot step (later today) I hope to > remove all the redundant (I think) macro use in the various device driver > source code files since that is dealt with by drivers.h. done (revision 8882): I tested this revision for shared libraries with and without dynamic devices enabled and for static libraries (dynamic devices must be disabled for that case). For all three cases and with CC, CXX, and FC set to default to hidden visibility, all was well (good build and ctest results) except for a libplplotwxwidgetsd library build issue for the static libraries case which probably has nothing to do with visibility and which I have reported to Werner off list. That's the end of my build and visibility testing for now, and I hope Werner and Arjen find these good results carry over to Windows platforms for a version of PLplot which includes most of the PLplot features (languages, device drivers, dynamic devices, etc.) that are available on Linux. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2008-10-14 21:16:48
|
Hi all, > Now to bring up a different, but related topic. Werner, do you know the > Windows library call (or calls) to dynamically load plug-ins? If so, I > think basically all you have to do to implement dynamic drivers on Windows > is replace the libltdl calls (lt_dlinit, lt_dlopenext, lt_dlsym, and > lt_dlexit) in src/plcore.c and drivers/get-drv-info.c by the equivalent > Windows library functions for the #if defined(WIN32) case. So long as you > know how to dynamically load on Windows, I don't think this will be a > particularly time-consuming project, and it really is time for the Windows > version of PLplot to get access to this nice feature that all the Unix > developers and users enjoy. it's now possible to load shared driver modules during run time on win32 platforms. What I did basically was to implement the ltdl API (parts of it) for Win32 in ltdl_win32.c/.h. I didn't look at the source of the ltdl library nor did I copy something from there, so I put this code under LGPL - no matter what license ltdl library has. I changed the CBS accordingly - since Cygwin and MSys provide very likely the ltdl library I excluded these toolkits from these changes. I had to define LTDL_WIN32 to keep it simple - this macro will also be defined in config.h. Together with some other minor changes this made the shared drivers work for MinGW. Visual C++ misses the dirent.h implementation so I downloaded a free one from here: http://www.softagalleria.net/dirent.php and included it in the svn repository. This implementation will only be used for Visual C++ compilers for now. Now it works for Visual C++ as well, except for a little crash :) at the exit of the examples. Very likely my ltdl implementation has some bugs, so this needs to be examined. Mind though, that from now on this is the default case on Windows, since ENABLE_DYN_DRIVERS is set by default (and won't be turned off if ltdl is not found, since we don't look for ltdl on win32). In order to get everything compiled you must put the ${CMAKE_BINARY_PATH}\dll directory in your PATH environment variable. Otherwise get-drv-info won't run and stops the compilation. Examples were run in the build tree. I'm not sure if this still works if the we run examples not from within the build tree since plplot won't find the *.rc files. This needs also to be investigated. I urge everybody to run tests even on non-win32 and win32 platforms, since I didn't test on Linux or Mac OS X if I broke something. Maybe I also forgot to commit something. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2008-10-15 05:42:39
|
On 2008-10-14 23:16+0200 Werner Smekal wrote: > I urge everybody to run tests even on non-win32 and win32 platforms, since I > didn't test on Linux or Mac OS X if I broke something. Maybe I also forgot to > commit something. Everything builds without any obvious errors on Linux, but the rest of the news is not good. All examples now immediately segfault on Linux with the default dynamic devices. Hez also reported the same issue to me off list. I haven't tried any other configuration, yet. I hope you or someone else here can quickly spot what the trouble is since a fix is urgent. I tried but failed. One thing that does work is ./get-drv-info when run in the build-tree drivers directory. But that is the only thing that works presently that I can see with dynamic devices. 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 __________________________ |