From: Alan W. I. <ir...@be...> - 2006-08-17 03:05:31
|
Hi Hazen: I just discovered that the variable names mentioned in our Darwin fortran workaround are not correct (assuming the correct names are given in $YOUR_CMAKE_INSTALL_PREFIX/share/CMake/Modules/CMakeFortranInformation.cmake). Everywhere "FORTRAN" occurred in a variable name I have now changed to "Fortran". Could you please revert back to an unmodifed CMake-2.4.3 (e.g, go back to the original form of $YOUR_CMAKE_INSTALL_PREFIX/share/CMake/Modules/Platform/Darwin.cmake) and try the latest workaround in PLplot CVS? It's possible this will solve the problems you were having with the fortran examples. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <hba...@ma...> - 2006-08-18 23:49:28
|
On Aug 16, 2006, at 11:04 PM, Alan W. Irwin wrote: > Hi Hazen: > > I just discovered that the variable names mentioned in our Darwin > fortran > workaround are not correct (assuming the correct names are given in > $YOUR_CMAKE_INSTALL_PREFIX/share/CMake/Modules/ > CMakeFortranInformation.cmake). > Everywhere "FORTRAN" occurred in a variable name I have now changed to > "Fortran". > > Could you please revert back to an unmodifed CMake-2.4.3 (e.g, go > back to > the original form of > $YOUR_CMAKE_INSTALL_PREFIX/share/CMake/Modules/Platform/ > Darwin.cmake) and > try the latest workaround in PLplot CVS? > > It's possible this will solve the problems you were having with the > fortran > examples. Thanks Alan! The fortran build tree examples now work correctly and have the correct library dependencies. iMac ~/Documents/OpenSource/PLplot/plplot-CBS-1/examples : otool -L ./ f77/x01f ./f77/x01f: /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/ bindings/f77/libplplotf77d.9.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/ bindings/f77/libplplotf77cd.9.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/src/ libplplotd.9.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/libltdl.3.dylib (compatibility version 5.0.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.6) /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/lib/ csa/libcsirocsa.0.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/lib/ nn/libcsironn.0.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/libqhull.5.dylib (compatibility version 6.0.0, current version 6.0.0) /usr/local/gfortran/lib/libgfortran.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/gfortran/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 93.0.0) -Hazen |
From: Arjen M. <arj...@wl...> - 2006-08-19 07:33:01
|
Hello, I have continued my experiments with MSVC/C++ 6.0 on Windows. Here are the results so far: 1. C and C++ work without problems. The only thing is that you need to copy the font files into the examples directory, otherwise PLplot can not find them. I have tried several drivers and they all seem to work okay, except for wingcc (the picture appears very briefly). 2. Compaq Visual Fortran is not recognised by CMake, so that is something (general) to sort out. 3. The issues with isnan() should be gone now: MSVC/C++ 6.0 reports a version 1200 and MSVC/C++ 2003 (the free toolkit) reports a version 1300. I have assumed that MSVC/C++ 2005 uses the same structure as the 2003 one, to define the special numbers Werner, can you confirm this? Next step: shared libraries. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-20 09:22:01
|
Hi Arjen, > 3. The issues with isnan() should be gone now: > MSVC/C++ 6.0 reports a version 1200 and MSVC/C++ 2003 (the > free toolkit) reports a version 1300. I have assumed > that MSVC/C++ 2005 uses the same structure as the 2003 > one, to define the special numbers > > Werner, can you confirm this? I can confirm, that Visual C++ reports 1400, that all examples compile without problem now, and I think that msvc 2003 and 2005 are very similar compilers, so the structure to define special numbers should be the same. The IDE changed a lot and the way to distribute executables - so that it's very had to distribute Visual C++ 2005 executables (at least for the express version), since the executable depend on strange libraries, which are not even for Windows XP SP 2 standard - I tried it once, but than gave up :). Werner |
From: Alan W. I. <ir...@be...> - 2006-08-19 15:31:30
|
On 2006-08-19 09:32+0200 Arjen Markus wrote: > Hello, > > I have continued my experiments with MSVC/C++ 6.0 on Windows. > Here are the results so far: > > 1. C and C++ work without problems. I still get a thrill of pleasure each time I see that result mentioned. That was just a gleam in our eye 6 weeks ago. We have come a very long way in a short time! > The only thing is that you need to copy the font files into > the examples directory, otherwise PLplot can not find them. What happens if you use ccmake to set the font-related variables (in particular the directory where fonts are found)? Once you find the correct font-related variable(s) to set, you can, of course, do it on the cmake command-line with the -C or -D options which is much more convenient than copying fonts each time you have a fresh build tree. > > I have tried several drivers and they all seem to work okay, > except for wingcc (the picture appears very briefly). This is a disappointing result since Werner reported the image disappearance problems are gone for the updated version that Andrew Roach checked in yesterday. I guess each of you has different tool chain/library versions installed so the device driver will have to be generalized some more to handle all cases or else there should be a test which eliminates those windows systems where this device driver will not work. Andrew, do you have access to MSVC/C++ 6.0 on Windows to see what the problem is? > > 2. Compaq Visual Fortran is not recognised by CMake, so that > is something (general) to sort out. Have a look at CMakeDetermineFortranCompiler.cmake. It appears from the cmake code (not the comments which incorrectly refer to the C case), that cmake recognizes the environment variable FC (and in fact does what looks like the right thing for any fortran compiler options you specify with that environment variable.) Anyhow, please let us know whether setting that environment variables solves your problems with compiler choice. > > 3. The issues with isnan() should be gone now: > MSVC/C++ 6.0 reports a version 1200 and MSVC/C++ 2003 (the > free toolkit) reports a version 1300. I have assumed > that MSVC/C++ 2005 uses the same structure as the 2003 > one, to define the special numbers > > Werner, can you confirm this? Your recent changes to c/x21c.c and nan.h now finally make them consistent. Thanks for that. But shouldn't the equivalent changes also be made for c++/x21.cc? > > Next step: shared libraries. > As I am sure you realize, that next step is an extremely important one. The Java and Python (and Octave) interfaces to PLplot require shared libraries. Thus, this step is fundamental to making PLplot on bare windows just as full featured as it is on Unix platforms. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-08-20 05:46:47
|
At 08:31 AM 19/08/2006 -0700, you wrote: >This is a disappointing result since Werner reported the image disappearance >problems are gone for the updated version that Andrew Roach checked in >yesterday. I guess each of you has different tool chain/library versions >installed so the device driver will have to be generalized some more to >handle all cases or else there should be a test which eliminates those >windows systems where this device driver will not work. > >Andrew, do you have access to MSVC/C++ 6.0 on Windows to see what the problem >is? No, I don't. -Andrew |
From: Werner S. <sm...@ia...> - 2006-08-20 08:57:22
|
Hi all, >> I have tried several drivers and they all seem to work okay, >> except for wingcc (the picture appears very briefly). > > This is a disappointing result since Werner reported the image disappearance > problems are gone for the updated version that Andrew Roach checked in > yesterday. I guess each of you has different tool chain/library versions > installed so the device driver will have to be generalized some more to > handle all cases or else there should be a test which eliminates those > windows systems where this device driver will not work. I tested the driver Andrew sent to me personally, and I just checked, that the new driver is also in cvs now. I think Arjen tested the old driver, not the new one, since this driver works for me on Visual C++ without problems (apart from the maximizing bug). MinGW has a problem though: [ 40%] Building C object src/CMakeFiles/plplotd.dir/__/__/drivers/wingcc.obj C:\DevZone\MinGW-3.4.5\bin\gcc.exe -IC:\DevZone\plplot\include -IC:\DevZone\plplot\buildmingw -IC:\DevZone\plplot\buildmingw\includ e -DHAVE_CONFIG_H -o src/CMakeFiles/plplotd.dir/__/__/drivers/wingcc.obj -c C:\DevZone\plplot\drivers\wingcc.c C:\DevZone\plplot\drivers\wingcc.c:592:43: macro "Debug" passed 2 arguments, but takes just 1 C:\DevZone\plplot\drivers\wingcc.c: In function `plD_init_wingcc': C:\DevZone\plplot\drivers\wingcc.c:592: error: `Debug' undeclared (first use in this function) C:\DevZone\plplot\drivers\wingcc.c:592: error: (Each undeclared identifier is reported only once C:\DevZone\plplot\drivers\wingcc.c:592: error: for each function it appears in.) C:\DevZone\plplot\drivers\wingcc.c:918:55: macro "Debug" passed 3 arguments, but takes just 1 C:\DevZone\plplot\drivers\wingcc.c: In function `Resize': C:\DevZone\plplot\drivers\wingcc.c:918: error: `Debug' undeclared (first use in this function) mingw32-make[2]: *** [src/CMakeFiles/plplotd.dir/__/__/drivers/wingcc.obj] Error 1 mingw32-make[2]: Leaving directory `C:/DevZone/plplot/buildmingw' mingw32-make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 mingw32-make[1]: Leaving directory `C:/DevZone/plplot/buildmingw' mingw32-make: *** [all] Error 2 The new Debug macro is obviously buggy? If I change line 150-154 to #define Verbose(...) do {if (pls->verbose){fprintf(stderr,__VA_ARGS__);}}while(0) #define Debug(...) do {if (pls->debug){fprintf(stderr,__VA_ARGS__);}}while(0) /* #define Debug(a) do {if (pls->debug){fprintf(stderr,(a));}}while(0) */ then it compiles again and works the same as in visual c++ build. So I think Arjen just needs to try it again after a cvs checkout. Andrew, could you please have a look in this debug macro issue (line 150-154)? Regards, Werner |
From: Andrew R. <aro...@ya...> - 2006-08-21 03:39:40
|
At 10:56 AM 20/08/2006 +0200, you wrote: >The new Debug macro is obviously buggy? If I change line 150-154 to > >#define Verbose(...) do {if >(pls->verbose){fprintf(stderr,__VA_ARGS__);}}while(0) >#define Debug(...) do {if (pls->debug){fprintf(stderr,__VA_ARGS__);}}while(0) > >/* #define Debug(a) do {if (pls->debug){fprintf(stderr,(a));}}while(0) */ > >then it compiles again and works the same as in visual c++ build. So I >think Arjen just needs to try it again after a cvs checkout. > >Andrew, could you please have a look in this debug macro issue (line 150-154)? I had not had a chance to test that change until just now, and like you found Arjen's change to the debug macro broke the MingW compile. Unfortunately, not having access to MSVC, I don't know how to change "the macro" so it satisfies both systems without adding conditional defines, so I have done just that. I hope I have used the correct symbol for MSVC to get it working. -Andrew |
From: Arjen M. <arj...@wl...> - 2006-08-21 04:44:57
|
> > I had not had a chance to test that change until just now, and like you > found Arjen's change to the debug macro broke the MingW compile. > > Unfortunately, not having access to MSVC, I don't know how to change > "the macro" so it satisfies both systems without adding conditional > defines, so I have done just that. I hope I have used the correct > symbol for MSVC to get it working. > Not quite, but I can sort that out. I just tried with the new sources: the black window has gone, I can now see the correct picture. But closing the program still causes an error window to pop-up - some heap corruption. So the problem we had before is unrelated to this issue. (I had similar issue with F77 on Cygwin) Well, one step at a time. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-21 09:11:44
|
Hi, > I just tried with the new sources: the black window has gone, > I can now see the correct picture. But closing the program still > causes an error window to pop-up - some heap corruption. So > the problem we had before is unrelated to this issue. > (I had similar issue with F77 on Cygwin) this heap corruption I also have for Visual C++ 2005. If I manage to let cmake make project/solution files (I'm close to, there is a small problem) than I'll able to debug it and provide a stacktrace for that. This heap corruption occurs only for wingcc driver, others don't have this problem. Regards, Werner -- Dipl. Ing. 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: Arjen M. <arj...@wl...> - 2006-08-21 04:30:54
|
> Hi all, > > I tested the driver Andrew sent to me personally, and I just checked, > that the new driver is also in cvs now. I think Arjen tested the old > driver, not the new one, since this driver works for me on Visual C++ > without problems (apart from the maximizing bug). > I updated my installation before trying this out, but that may have been too early :). I will try again asap. > The new Debug macro is obviously buggy? If I change line 150-154 to > > #define Verbose(...) do {if > (pls->verbose){fprintf(stderr,__VA_ARGS__);}}while(0) > #define Debug(...) do {if > (pls->debug){fprintf(stderr,__VA_ARGS__);}}while(0) > > /* #define Debug(a) do {if (pls->debug){fprintf(stderr,(a));}}while(0) > */ > > then it compiles again and works the same as in visual c++ build. So I > think Arjen just needs to try it again after a cvs checkout. > > Andrew, could you please have a look in this debug macro issue (line > 150-154)? > > The macro definition with the ellipsis caused problems under MSVC/C++ 6.0 - it does not like them. That is why I changed the macro. A very brief inspection seemed to show calls with only one argument. Hence the change. (MSVC/C++ 6.0 does _not_ complain about the two calls I found just now with more than one argument. Odd.) Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-21 09:06:48
Attachments:
pldll.h
plplot.patch
|
Hi list, I made the changes proposed yesterday, since they turned out to be easier than I thought. Attached is a patch (diff -Naur -x Entries* -x Repository -x Root -x desktop.ini plplot plplot_dll >plplot.patch) and a missing include file (which somehow got lost and therefore not included in the patch). THe patch has to be applied to the current cvs build. The include file pldll.h goes into the include directory. I made the following changes (and actually didn't touch any *.c file): * pldll.h contain the dll macro stuff and is included by plplot.h and pdf.h * plplot.h, pdf.h and plplotP.h have now PLDLLIMPEXP in front of functions to be exported. I exported every function in plplot.h, and only functions needed to compile the examples and utils (pltek and plrender) in pdf.h and plplotP.h (this needs to be considered) * I made changed to CMakelist.txt so that the compiler option -DMAKINGPLDLL is included when the library is build and -DUSINGPLDLL for examples and utils (if WIN32 and BUILD_SHARED_LIB) * I made also changes to the c++ bindings so that the plstream class is exported * and also one small change to export plsc in plcore.h result: on MinGW: cmake -G "MinGW Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=plplot_install -DBUILD_SHARED_LIBS=ON -DBUILD_TEST=ON .. Everything compiles. Examples run if I: * cd examples\c * copy ..\..\..\data\*.fnt . * copy ..\..\src\libplplotd.dll . * copy ..\..\lib\csa\libcsirocsa.dll . * copy "..\..\bindings\c++\libplplotcxxd.dll" . (if c++) on Visual C++ 2005: cmake -G "NMake Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=plplot_install -DBUILD_SHARED_LIBS=ON -DBUILD_TEST=ON .. Everything compiles. Examples run if I: * cd examples\c or cd examples\c++ * copy ..\..\src\plplotd.dll . * copy "..\..\bindings\c++\plplotcxxd.dll" . (if c++) * copy ..\..\..\data\*.fnt . I would be glad if someone (arjen?) could test the patch and we could discuss how we should proceed from here. Dynamic device drivers should also be not too much a problem now. Regards, Werner |
From: Werner S. <sm...@ia...> - 2006-08-21 09:09:56
|
Hi, >> then it compiles again and works the same as in visual c++ build. So I >> think Arjen just needs to try it again after a cvs checkout. >> >> Andrew, could you please have a look in this debug macro issue (line >> 150-154)? >> >> > > The macro definition with the ellipsis caused problems under MSVC/C++ 6.0 > - it does not like them. That is why I changed the macro. A very brief > inspection seemed to show calls with only one argument. Hence the > change. (MSVC/C++ 6.0 does _not_ complain about the two calls I found > just now with more than one argument. Odd.) Ok, I now remember, why I use debug functions for the wxWidgets driver and not macros :). Not all compiler accept ellipsis for macros - and using macros with one argument while it was defined with only one is not accepted by others. So you can use either functions with ellipsis (like in the wxWidgets driver) or use some #ifdef magic :) Regards, Werner > > Regards, > > Arjen > > > > -- Dipl. Ing. 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...> - 2006-08-21 17:08:27
|
On 2006-08-21 11:06+0200 Werner Smekal wrote: > Hi list, > > I made the changes proposed yesterday, since they turned out to be easier > than I thought. Attached is a patch (diff -Naur -x Entries* -x Repository -x > Root -x desktop.ini plplot plplot_dll >plplot.patch) and a missing include > file (which somehow got lost and therefore not included in the patch). THe > patch has to be applied to the current cvs build. The include file pldll.h > goes into the include directory. > > I made the following changes (and actually didn't touch any *.c file): ... I had a quick look at the patch, and I liked what I saw. Most of the changes were centralized to plplot.h and not scattered all over the source code. I applied the patch to my local tree; changed SET_SOURCE_FILES_PROPERTIES(x${STRING_INDEX}c x${STRING_INDEX}c.c to SET_SOURCE_FILES_PROPERTIES(x${STRING_INDEX}c.c in examples/c/CMakeLists.txt (since x${STRING_INDEX}c is an executable and not source code), added include/pldll.h (modified by putting a CR at the end of the file), and PLplot built from scratch (with no additional warnings), and ctest ran without any problems on Linux. I suspect additional changes will need to be made to accomodate the wide variety of windows needs. Nevertheless, it appears from Werner's good results for his windows tool chain that this is a good start for shared library support on windows. Thus, I have gone ahead and made the commits (of my slightly modified versions) to CVS as the basis for further discussion. Arjen and Andrew (Roach), let us know if this also works for you. 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2006-08-21 19:47:55
|
> On 2006-08-21 11:06+0200 Werner Smekal wrote: > > I suspect additional changes will need to be made to accomodate the > wide variety of windows needs. Nevertheless, it appears from Werner's > good results for his windows tool chain that this is a good start for > shared library support on windows. Thus, I have gone ahead and made > the commits (of my slightly modified versions) to CVS as the basis for > further discussion. > > Arjen and Andrew (Roach), let us know if this also works for you. > Well, it seems to compile a lot, but when it comes to the CSA library, I get the same failure as before: the csirocsa.lib import library is missing. I have tried to turn it off via -DWITH_csa:BOOL=OFF, but that did not work. No time anymore to go the next step (turn it off via a temporary change in the source code or something). Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-22 05:41:16
|
Hi Arjen, > Well, it seems to compile a lot, but when it comes to the CSA > library, I get the same failure as before: the csirocsa.lib import > library is missing. > > I have tried to turn it off via -DWITH_csa:BOOL=OFF, but that did > not work. No time anymore to go the next step (turn it off via > a temporary change in the source code or something). for my system it doesn't try to compile the csa library - therefore I also didn't touch it - and if it also should be shared, we also need to export the necessary functions. I'll have a look, why it doesn't get turned on for my system and than try to export the necessary functions to let everything compile again. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-21 22:37:21
|
On 2006-08-21 21:47+0200 Arjen Markus wrote: >> On 2006-08-21 11:06+0200 Werner Smekal wrote: >> > >> I suspect additional changes will need to be made to accomodate the >> wide variety of windows needs. Nevertheless, it appears from Werner's >> good results for his windows tool chain that this is a good start for >> shared library support on windows. Thus, I have gone ahead and made >> the commits (of my slightly modified versions) to CVS as the basis for >> further discussion. >> >> Arjen and Andrew (Roach), let us know if this also works for you. >> > > Well, it seems to compile a lot, but when it comes to the CSA > library, I get the same failure as before: the csirocsa.lib import > library is missing. > Arjen, please send more details. Without those, I am forced to speculate too much for comfort. It appears your CMake system finds all the right conditions to set WITH_CSA ON. This forces libcsirocsa to be built (I assume). In turn this creates a dependency for the libplplotd build, but there is some windows (linking?) issue there so it cannot find the libcsirocsa library that was built. Arjen, please check in the build tree whether libcsirocsa has really been built. Assuming it has been build, from your windows linking experience can you figure out why it is not found? Werner, when you do your builds, is WITH_CSA OFF or ON? (look at the summary from cmake). If OFF, that means you have not really tested the libcsirocsa build like Arjen has done. To attempt to replicate this bug, you will have to solve whatever issue is forcing CMake to turn WITH_CSA OFF. (Look for WARNING messages from cmake.) If ON, then obviously you are having no problems with the dependency issue, and it is likely there is some tool chain difference between Arjen's system and yours that is causing the problem. > I have tried to turn it off via -DWITH_csa:BOOL=OFF, but that did > not work. That's because case is important. Some of our variables are multi-case but this one is all upper case. So -DWITH_CSA=OFF should bypass the problem. (By the way, :BOOL used to be necessary with old versions of CMake, but it is no longer necessary. Also, be sure the cache file is removed before you run cmake so that the -D options will be honored.) For now, Arjen, it is probably better not to bypass the issue and instead solve it with your windows linking expertise. 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2006-08-22 04:38:00
|
> On 2006-08-21 21:47+0200 Arjen Markus wrote: > >>> On 2006-08-21 11:06+0200 Werner Smekal wrote: >>> >> >>> I suspect additional changes will need to be made to accomodate the >>> wide variety of windows needs. Nevertheless, it appears from >>> Werner's good results for his windows tool chain that this is a good >>> start for shared library support on windows. Thus, I have gone ahead >>> and made the commits (of my slightly modified versions) to CVS as the >>> basis for further discussion. >>> >>> Arjen and Andrew (Roach), let us know if this also works for you. >>> >> >> Well, it seems to compile a lot, but when it comes to the CSA >> library, I get the same failure as before: the csirocsa.lib import >> library is missing. >> > > Arjen, please send more details. Without those, I am forced to > speculate too much for comfort. The situation is this: - The CSA library is built as a separate component so to speak. - In case of static libraries, this results in a csirocsa.lib that can be linked against or that can be merged into another library, such as plplotd.lib. - In case of dynamic/shred libraries, this results in a csirocsa.dll, but _not_ in a csirocsa.lib because no functions from the CSA library are actually exported. (I need to solve this in the same way as Werner has done for the PLplot library itself). > > Arjen, please check in the build tree whether libcsirocsa has really > been built. Assuming it has been build, from your windows linking > experience can you figure out why it is not found? > Yes, it builds csirocsa.dll, but that is not enough on Windows. See above. > Werner, when you do your builds, is WITH_CSA OFF or ON? (look at the > summary from cmake). If OFF, that means you have not really tested the > libcsirocsa build like Arjen has done. To attempt to replicate this > bug, you will have to solve whatever issue is forcing CMake to turn > WITH_CSA OFF. (Look for WARNING messages from cmake.) If ON, then > obviously you are having no problems with the dependency issue, and it > is likely there is some tool chain difference between Arjen's system > and yours that is causing the problem. > >> I have tried to turn it off via -DWITH_csa:BOOL=OFF, but that did not >> work. > > That's because case is important. Some of our variables are multi-case > but this one is all upper case. So -DWITH_CSA=OFF should bypass the > problem. (By the way, :BOOL used to be necessary with old versions of > CMake, but it is no longer necessary. Also, be sure the cache file is > removed before you run cmake so that the -D options will be honored.) > Stupid! Yes, I have tried again and now CSA is turned off. Parameters set on the command-line always seem to be honored, so that makes life a bit easier. > For now, Arjen, it is probably better not to bypass the issue and > instead solve it with your windows linking expertise. > Sounds fair enough, but later we will need to decide how we are going to do this: Do we want separate libraries (lib)plplotd.so/dll and (lib)csirocsa.so/dll or not? (How do we do it in the ABS? Can't find it righ now) Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-22 05:51:35
|
Hi all, > It appears your CMake system finds all the right conditions to set WITH_CSA > ON. This forces libcsirocsa to be built (I assume). In turn this creates a > dependency for the libplplotd build, but there is some windows (linking?) > issue there so it cannot find the libcsirocsa library that was built. As Arjen already wrote, there is nothing exported (with this __declspec(dllexport) stuff), so visual c++ doesn't create a *.lib file, though a dll exists. > > Werner, when you do your builds, is WITH_CSA OFF or ON? (look at the > summary from cmake). For me it's off. It was on weeks ago and than suddenly was off, so I thought this was for purpose. I'll try to find out why it's off for me. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-22 06:16:02
|
On 2006-08-22 06:37+0200 Arjen Markus wrote: > The situation is this: > - The CSA library is built as a separate component so to speak. > - In case of static libraries, this results in a csirocsa.lib > that can be linked against or that can be merged into > another library, such as plplotd.lib. > - In case of dynamic/shred libraries, this results in a > csirocsa.dll, but _not_ in a csirocsa.lib because no > functions from the CSA library are actually exported. > (I need to solve this in the same way as Werner has done > for the PLplot library itself). Thanks for that clarification. >> For now, Arjen, it is probably better not to bypass the issue and ^^^ >> instead solve it with your windows linking expertise. >> > > Sounds fair enough, but later we will need to decide how we are going to > do this: Actually, I think you misread what I said above, and I assume you want to make this decision now since it should be entirely straightforward. > Do we want separate libraries (lib)plplotd.so/dll and (lib)csirocsa.so/dll > or not? (How do we do it in the ABS? Can't find it righ now) I know it is true that on windows you need to produce two files to make the equivalent of a Linux shared library, but that's the limit of my windows shared library knowledge. On Linux it is one file + two symlinks to that file, but below to keep the discussion simple I will refer to a shared library as one entity on both platforms. Anyhow, to answer your question, for the shared libraries case (for both CBS and ABS) on Linux we build the following three separate shared libraries: libplplotd, libcsirocsa, and libcsironn. Note, that libplplotd links to the other two (has symbols that are resolved by the other two). The three library builds and the linking between them is currently all automatically set up by our CBS so I think all you have to do is export functions from both libcsirocsa and libcsironn (generalizing what you said above) to get rid of the errors you have encountered. Hope that overview of how the three separate libplplotd, libcsirocsa, and libcsironn shared libraries are related clarifies this aspect of our CBS for you. 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2006-08-22 06:37:35
|
On 2006-08-22 07:51+0200 Werner Smekal wrote: >> Werner, when you do your builds, is WITH_CSA OFF or ON? (look at the >> summary from cmake). > > For me it's off. It was on weeks ago and than suddenly was off, so I thought > this was for purpose. I'll try to find out why it's off for me. Thanks. One other issue is I just realized that probably both Arjen and you are also skipping the build of libcsironn (which would have similar shared library issues to libcsirocsa) because you don't have libqhull installed (i.e., your summaries will say HAVE_QHULL OFF). There is a windows download of qhull available at http://www.qhull.org/download/ but I don't know whether or not it is in library form that can be used by our CBS. If a qhull library is readily available to you, then you should both pay attention to the libcsironn remarks I made before (as well as the libcsirocsa remarks I made). 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 Yorick front-end to PLplot (yplot.sf.net); 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...> - 2006-08-20 09:17:20
|
Hi all, >> Next step: shared libraries. >> > As I am sure you realize, that next step is an extremely important one. The > Java and Python (and Octave) interfaces to PLplot require shared libraries. > Thus, this step is fundamental to making PLplot on bare windows just as full > featured as it is on Unix platforms. I propose again, that we invest here the time in the more common solution. In the libraries which are cross platform and I had a look in the source code, they always use some macros, which define e.g. PLDLLIMPEXP macro which is __declspec(dllexport) or __declspec(dllimport) on Win32 or nothing otherwise. Especially wxWidgets does it also that way, and there are good win32 developers there, so think this is kind of standard (for a cross platform library). The plstubs.cpp is not the best solution (in my opinion), since it's another interface you have to keep in sync with the plplot api and the header file in sys/win32/msdev has a lot of redefinitions of functions, which were not necessary if you use the common macros (see below). I also see a problem here, since you not only have to include the plstubs.cpp file (which is easy), but also need to replace the standard plplot.h header file, with the win32 one (which might not be easy to do it an elegant way), or let the compiler find before he finds the standard header file. To my knowledge, you have only to inlclude some macros in plplot.h, like this one: #if defined(WIN32) /* Visual C/C++, Borland, MinGW and Watcom */ #if defined(__VISUALC__) || 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) #endif #ifndef PLDLLEXPORT # define PLDLLEXPORT # define PLDLLIMPORT #endif #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 and than put an PLDLLIMPEXP before every function you want to export (make available to the programmer) and PLDLLIMPEXP_DATA(type) for every variable or class we won't to export (if any). This is in my opinion not bad at all, since the programmer sees with on glance, which function is going to be exported and which not. You also have to add -DMAKINGPLDLL if you compile the shared library and -DUSINGPLDLL if you use the shared library in your program. I've to admit, that I'm not 100% sure about everything, but I wanted to ask the wxWidgets mailing list (who are very helpful normally) about this issue. As I said, I would help to implement this solution. Or I could just do it on my own and if I succeed I send you the patches. But than Arjen would do the implementation of the stubs file for nothing. Or you just disagree to implement such an solution at all (which is perfectly ok), than I don't invest more time in this issue. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-19 01:12:31
|
On 2006-08-18 19:48-0400 hba...@ma... wrote: > The fortran build tree examples now work correctly and have the correct > library dependencies. Good. As I recall, the next Mac OS X issue was python, but I cannot remember the symptoms you reported. Note, I have recently cleaned up the build-tree and install-tree python examples so it might just work for you. However, if you continue to have python problems I suggest you locally modify python.cmake (using the CMake message command to dump all the python-related variables) to see if you can spot a wrong directory or whatever. Then look carefully at the make step that is failing and compare with the equivalent ABS result that works. Probably your best resource here is Per who seems to understand Mac OS X linking issues completely. However, I would be happy to help if you know what is required, but you need some CMake expertise to implement your solution. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2006-08-20 23:46:48
|
On Aug 18, 2006, at 9:10 PM, Alan W. Irwin wrote: > > As I recall, the next Mac OS X issue was python, but I cannot > remember the > symptoms you reported. Note, I have recently cleaned up the build- > tree and > install-tree python examples so it might just work for you. Yes that is the next issue. I can "make" with Python if I use ccmake to set CMAKE_MODULE_LINKER_FLAGS to "-flat_namespace -undefined suppress". I'm worried that this is a shotgun approach because in the ABS these flags were only used for Python. It also isn't clear to me whether or not it would work if I did not already have plplot installed on my system. The relevant line: /usr/bin/gcc -bundle -headerpad_max_install_names -flat_namespace - undefined suppress -o _plplotcmodule.so "CMakeFiles/ _plplotcmodule.dir/plplotcmodulePYTHON_wrap.o" -L/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-CBS-2/src -L/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-CBS-2/lib/csa -L/Users/hbabcock/ Documents/OpenSource/PLplot/plplot-CBS-2/lib/nn -L/usr/local/lib - lplplotd -lltdl -ldl -lm -lcsirocsa -lcsironn -lqhull Seems to be linking against stale libraries in /usr/local/lib. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-08-21 08:07:30
|
On 2006-08-20 19:45-0400 Hazen Babcock wrote: > I can "make" with Python if I use ccmake to set > CMAKE_MODULE_LINKER_FLAGS to "-flat_namespace -undefined suppress". I'm > worried that this is a shotgun approach because in the ABS these flags were > only used for Python. I think you can just specify these flags in bindings/python/CMakeLists.txt. One method which might work is the following: if(APPLE) swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES} "-flat_namespace" "-undefined suppress" ) else (APPLE) swig_link_libraries(plplotcmodule plplot${LIB_TAG}) endif(APPLE) Alternatively, CMAKE_MODULE_LINKER_FLAGS is in the cache so I think to avoid the shotgun approach you could in bindings/python/CMakeLists.txt save the value in a temporary variable, set the CMAKE_MODULE_LINKER_FLAGS cache value, link all the python related stuff, and then restore the cache value from the temporary variable. Note, for the APPLE case above I tentatively used ${PYTHON_LIBRARIES}. This is not needed in the Linux case, but it might be defined AND needed in the Mac OS X case (depending on how python itself is linked) and it might let you drop one or both of the -flat_namespace -undefined suppress parameters. Let me know if ${PYTHON_LIBRARIES} allows you to drop both special linking options. If that is the case then we could replace the above complicated logic by swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES}) > It also isn't clear to me whether or not it would work > if I did not already have plplot installed on my system. The relevant line: > > /usr/bin/gcc -bundle -headerpad_max_install_names -flat_namespace - > undefined suppress -o _plplotcmodule.so "CMakeFiles/ > _plplotcmodule.dir/plplotcmodulePYTHON_wrap.o" -L/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-CBS-2/src -L/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-CBS-2/lib/csa -L/Users/hbabcock/ > Documents/OpenSource/PLplot/plplot-CBS-2/lib/nn -L/usr/local/lib -lplplotd > -lltdl -ldl -lm -lcsirocsa -lcsironn -lqhull > > Seems to be linking against stale libraries in /usr/local/lib. That's not clear from the above since Documents/OpenSource/PLplot/plplot-CBS-2/src presumably refers to the correct location of libplplotd and -L/usr/local/lib could be referring to any of the other libraries mentioned such as libltdl or libqhull rather than the stale libplplotd. I suggest using otool on _plplotcmodule.so in both the build tree and install tree to make sure the correct versions of all the libraries are being found in the two cases with no stale libraries being used (even though stale libraries are available). However, to make doubly sure you can always remove the stale libplotd from /usr/local/lib, and always use a less generic install prefix from then on so you won't have to be concerned about this again. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |