From: Arjen M. <arj...@wl...> - 2006-08-15 19:45:57
|
Hi all, I wanted to keep you all in suspense about my latest experiments with CMake on bare Windows, but the tension was too much! It works! Well, that is: I can make the PLplot library and most C examples using MSVC/C++ 6.0. The one that is currently failing is x21c (because of isnan again, but I can fix that). Of course, I have turned off all devices, except for PostScript, and I have only C and C++ bindings on. But - I think this is a major breakthrough. Next steps: - get isnan() worked out - turn on more devices - turn on more languages For the record, these are my CMake settings: c:\arjen\cmake\install\bin\debug\cmake -DBUILD_SHARED_LIBS:BOOL=OFF -DDEFAULT_NO_DEVICES:BOOL=ON -DPLD_ps:BOOL=ON -DBUILD_TEST:BOOL=ON -DENABLE_tcl:BOOL=OFF -DENABLE_tk:BOOL=OFF -DENABLE_wingcc:BOOL=OFF -DENABLE_f77:BOOL=OFF -G "NMake Makefiles" . (Oh, what joy it is to just type a few commands and have everything built! Yes, I am a command-line kind of guy :) And forgive me my euphoria) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-08-15 20:02:55
|
> Well, that is: I can make the PLplot library and most C examples > using MSVC/C++ 6.0. The one that is currently failing is x21c > (because of isnan again, but I can fix that). > Example x21c: - I needed to add the same code to lib/csa/nan.h as I had to for the CMake test - I needed to include that file in the souce for x21c Then it worked - as far as I can tell (I have only a limited number of interpolation options) and a only very primitve PS viewer. However, I had to add the relative path "..\\..\\lib\csa" to the include statement. CMake seems to be picking it up but not in the makefile. Maybe a leftover from before? Anyway, I am going to check in the new sources. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-15 20:16:50
|
Hi, I also was just successfull with Visual C++ 2005 using the wingcc driver. I'll post more tomorrow, since I need some sleep now :) regards, Werner Arjen Markus wrote: >> Well, that is: I can make the PLplot library and most C examples >> using MSVC/C++ 6.0. The one that is currently failing is x21c >> (because of isnan again, but I can fix that). >> > > Example x21c: > - I needed to add the same code to lib/csa/nan.h as I had to for the > CMake test > - I needed to include that file in the souce for x21c > > Then it worked - as far as I can tell (I have only a limited > number of interpolation options) and a only very primitve PS viewer. > > However, I had to add the relative path "..\\..\\lib\csa" to the > include statement. CMake seems to be picking it up but not in the makefile. > Maybe a leftover from before? > > Anyway, I am going to check in the new sources. > > Regards, > > Arjen > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2006-08-15 22:19:03
|
On 2006-08-15 22:02+0200 Arjen Markus wrote: > >> Well, that is: I can make the PLplot library and most C examples >> using MSVC/C++ 6.0. The one that is currently failing is x21c >> (because of isnan again, but I can fix that). >> > > Example x21c: > - I needed to add the same code to lib/csa/nan.h as I had to for the > CMake test That commit makes sense. > - I needed to include that file in the souce for x21c For the life of me I cannot see why that change is necessary. All that nan.h does is #define NaN, but NaN is not used in x21c.c (unless buried deep in the include chain where I cannot find it). If you simply go back to the previous x21c.c change do you have any problems? If not, please revert your commit. If so, what are the details of those problems (i.e., where is NaN actually used?) If necessary we could do something special in plcdemos.h to #define NaN for the bare windows case, but at this point I don't see why it is necessary. 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-15 22:51:30
|
On 2006-08-15 15:18-0700 Alan W. Irwin wrote: > For the life of me I cannot see why that change is necessary. All that > nan.h does is #define NaN... Oops. Actually, that was the old nan.h. I see now that the new one does #define isnan _isnan in the bare windows case and this is obviously needed for example 21. To make our life a bit simpler I have just made the additional change of replacing #include "nan.h" by #if defined(_WIN32) && defined(_MSC_VER) #define isnan _isnan #endif in x21c.c. Then we don't have to worry about adding the extra -I option to find nan.h in the build tree, and we don't have to install nan.h so that the installed examples work. Please test that my change works for you. In particular I wasn't sure whether #include <float.h> #include <ymath.h> were needed or not to determine _isnan. Please put them in if they are needed. 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-16 04:28:52
|
> On 2006-08-15 15:18-0700 Alan W. Irwin wrote: > >> For the life of me I cannot see why that change is necessary. All >> that nan.h does is #define NaN... > > Oops. Actually, that was the old nan.h. I see now that the new one > does > > #define isnan _isnan > > in the bare windows case and this is obviously needed for example 21. > > To make our life a bit simpler I have just made the additional change > of replacing > > #include "nan.h" > > by > > #if defined(_WIN32) && defined(_MSC_VER) > #define isnan _isnan > #endif > > in x21c.c. > > Then we don't have to worry about adding the extra -I option to find > nan.h in the build tree, and we don't have to install nan.h so that the > installed examples work. > > Please test that my change works for you. In particular I wasn't sure > whether > > #include <float.h> > #include <ymath.h> > > were needed or not to determine _isnan. Please put them in if they are > needed. > Right, ymath.h is needed for the actual "value" of NaN, but without that it should still work. Not sure about float.h, as this defines _isnan() ... I will give it a go, though. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-08-16 04:35:48
|
Last night's success made me a daredevil, so I went for the Cygwin platform too, just to see what would happen. Configuring is no problem, but building is: include/CMakeFiles/plhershey-unicode-gen.dir/build.make:49: *** target pattern contains no `%'. Stop. make[1]: *** [include/CMakeFiles/plhershey-unicode-gen.dir/all] Error 2 make: *** [all] Error 2 I tried to clean up and start anew, but that makes no difference, the same error occurs. So, I removed the complete build tree and tried again: same result! Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-16 16:08:00
|
On 2006-08-16 06:35+0200 Arjen Markus wrote: > Last night's success made me a daredevil, so I went for the Cygwin > platform too, just to see what would happen. > > Configuring is no problem, but building is: > > include/CMakeFiles/plhershey-unicode-gen.dir/build.make:49: *** target > pattern contains no `%'. Stop. > make[1]: *** [include/CMakeFiles/plhershey-unicode-gen.dir/all] Error 2 > make: *** [all] Error 2 > > I tried to clean up and start anew, but that makes no difference, the > same error occurs. > > So, I removed the complete build tree and tried again: same result! Here is the code (from include/CMakeLists.txt) that generates this: set(plhershey-unicode-gen_SRCS ${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode-gen.c ) add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS}) add_custom_target( plhershey-unicode.h ALL ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT} ${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv plhershey-unicode.h DEPENDS ${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv ) add_dependencies(plhershey-unicode.h plhershey-unicode-gen) That cmake code works fine on Linux (the Unix makefile generator) and also bare windows (nmake? generator). Are you using the appropriate generator (presumably Unix makefile) for Cygwin? If so, then you have probably found a CMake bug for that generator on Cygwin, and you should ask the CMake list for advice giving full details (your cmake invocation, the CMake code above, your error message, and the complete file, include/CMakeFiles/plhershey-unicode-gen.dir/build.make). If they agree it is a bug, they will ask you to fill out a bug report. 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-16 20:06:55
|
Hi, I compiled plplot cvs on cygwin with the following commands (static lib): * cd plplot * mkdir buildcygwin * cd buildcygwin * cmake -G "Unix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=plplot_install -DBUILD_SHARED_LIBS=OFF -DENABLE_tk=OFF -DENABLE_tcl=OFF -DBUILD_TEST=ON .. * make * optional to test library: * cd examples/c * cp ../../../data/*.fnt . * x01c I had to switch tcl/tk off for the moment since I got a lot of compiler errors. If turned off it turns also wingcc driver on and all compiles fine, also all examples (mind though that this is only true for my changed examples code as mailed before). Arjen, maybe you should try to set the generator with -G "Unix Makefiles"? Do you have the latest cmake 2.4.3? Regards, Werner PS: wingcc driver "works", but it doesn't refresh properly, so there is some work necessary for this driver. -- 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-17 06:25:09
|
Alan W. Irwin wrote: > On 2006-08-16 06:35+0200 Arjen Markus wrote: > >> Last night's success made me a daredevil, so I went for the Cygwin >> platform too, just to see what would happen. >> >> Configuring is no problem, but building is: >> >> include/CMakeFiles/plhershey-unicode-gen.dir/build.make:49: *** target >> pattern contains no `%'. Stop. >> make[1]: *** [include/CMakeFiles/plhershey-unicode-gen.dir/all] Error 2 >> make: *** [all] Error 2 >> >> I tried to clean up and start anew, but that makes no difference, the >> same error occurs. >> Your remarks led me to examine the makefiles and the version of make that I have. The cause is the use of the drive letter in the makefiles! I updated Cygwin because of pkg-config and got make 3.81 in the process. This does not like paths that have c:/ in them. The solution is to revert to 3.80 or to use a CMake built for Cygwin. I have not tested that yet. I think I wil report this on the CMake list too - but first I need to sort out the details. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-17 14:53:39
|
On 2006-08-17 08:25+0200 Arjen Markus wrote: > Your remarks led me to examine the makefiles and the version of make > that I have. > The cause is the use of the drive letter in the makefiles! Congratulations for figuring out the drive-letter problem. That's the key to the whole Cygwin issue. It turns out that problem has been thoroughly discussed on the CMake list three days ago. See http://public.kitware.com/pipermail/cmake/2006-August/010617.html for the start of the thread. As you have found, the windows version of CMake and the updated Cygwin gmake (which does not allow drive letters) do not work well together for the "Unix Makefiles" generator. For that generator you have the following three choices on the Cygwin platform: use the Cygwin version of CMake; use the windows version of CMake and an old version of Cygwin gmake; or use the windows version of CMake and the MinGW version of gmake (download instructions in the above e-mail). 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-17 16:43:57
|
> On 2006-08-17 08:25+0200 Arjen Markus wrote: > >> Your remarks led me to examine the makefiles and the version of make >> that I have. >> The cause is the use of the drive letter in the makefiles! > > Congratulations for figuring out the drive-letter problem. That's the > key to the whole Cygwin issue. > ... > > For that generator you have the following three choices on the Cygwin > platform: use the Cygwin version of CMake; That was my choice - CMake can be readily built on Cygwin using the bootstrap script and make. So, that done, I continued the experiments: 1. Disabling all drivers, except PS, and shared libraries off: C and Fortran 90/95 (gfortran) work splendidly! However: C++ failed, the linker complained about plstream::plinit and the like. 2. Enabling all drivers, and shared libraries on: I got an error about an unresolved reference lt_dlinit() 3. Enabling all drivers, shared libraries off: Complaints from the compiler (gcc) about tkwin.c: a parse error (if I remember correctly) about "nmemb" at line 1823. 4. Enabling more drivers than PS (shared libraries off, Tcl/Tk off): None work - I get error messages about plD_dispatch_init_wingcc and the like. If I allow one of the drivers connected to the GD library (which is found on the system), then I get a message from gcc that it can not find "cygz" - just that, no extension. Note: To turn off the GD drivers I had to turn off all of GIF, JPEG, PNG. At least a parameter PLD_gd does not exist, even though gd is mentioned in the overview. Well, that is it at the moment. We are making progress, even if one would like to leap forward instead going step by step. (No changes yet to the examples) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-17 19:24:39
|
On 2006-08-17 18:43+0200 Arjen Markus wrote: > [...] I continued the experiments: > > 1. Disabling all drivers, except PS, and shared libraries off: > C and Fortran 90/95 (gfortran) work splendidly! Excellent. > > However: > C++ failed, the linker complained about plstream::plinit and the > like. Werner do you have this Cygwin issue? I don't recall whether you use the gcc tool chain or not. Arjen, I wonder if you have a problem with your gcc tool chain on Cygwin since the gcc tool chain works fine on Linux. Is your installed g++ Cygwin package consistent (in version number) with your installed gcc Cygwin package? On my two Linux platforms I get the following version results: irwin@chickadee> gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. irwin@chickadee> g++ --version g++ (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. irwin@starling> gcc --version gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. irwin@starling> g++ --version g++ (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Both the chickadee (Debian stable) and starling (Ubuntu Dapper) platforms have self-consistent gcc tool chains that work well. > 3. Enabling all drivers, shared libraries off: > Complaints from the compiler (gcc) about tkwin.c: > a parse error (if I remember correctly) about "nmemb" at > line 1823. Please give the exact error message (with a lot of surrounding context) and not a paraphrase. > > 2. Enabling all drivers, and shared libraries on: > I got an error about an unresolved reference lt_dlinit() Unless you are fiddling with CMakeCache.txt this should not happen. There is a test for the presence of libltdl (which apparently passed in your case), but somehow that information is not getting to the actual build. Please give your CMake command (starting from an empty build tree), your complete CMake output, and your complete make output. > > 4. Enabling more drivers than PS (shared libraries off, Tcl/Tk off): > None work - I get error messages about plD_dispatch_init_wingcc > and the like. Probably we should wait to deal with this issue until 2 is solved. 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-18 04:41:34
|
Hi Alan, > > Arjen, I wonder if you have a problem with your gcc tool chain on > Cygwin since the gcc tool chain works fine on Linux. Is your installed > g++ Cygwin package consistent (in version number) with your installed > gcc Cygwin package? On my two Linux platforms I get the following > version results: > I have: bash-3.1$ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.1$ g++ --version g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.1$ So that seems fine. > >> 3. Enabling all drivers, shared libraries off: >> Complaints from the compiler (gcc) about tkwin.c: >> a parse error (if I remember correctly) about "nmemb" at >> line 1823. > > Please give the exact error message (with a lot of surrounding context) > and not a paraphrase. > >> >> 2. Enabling all drivers, and shared libraries on: >> I got an error about an unresolved reference lt_dlinit() > > Unless you are fiddling with CMakeCache.txt this should not happen. > There is a test for the presence of libltdl (which apparently passed in > your case), but somehow that information is not getting to the actual > build. > > Please give your CMake command (starting from an empty build tree), > your complete CMake output, and your complete make output. > Using the following command-line (left all drivers on by mistake): /cygdrive/c/arjen/cmake-cygwin/CMake/bin/cmake -DBUILD_TEST:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=OFF -DDEFAULT_NO_DEVICES:BOOL=OFF -DPLD_ps:BOOL=ON -G "Unix Makefiles" ../plplot in the build directory I get (from make): /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1823: error: parse error before "nmemb" /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c: In function `ckcalloc': /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: `size' undeclared (first use in this function) /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: (Each undeclared identifier is reported only once /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: for each function it appears in.) /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: `nmemb' undeclared (first use in this function) make[2]: *** [src/CMakeFiles/plplotd.dir/cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.o] Error 1 make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 make: *** [all] Error 2 >> >> 4. Enabling more drivers than PS (shared libraries off, Tcl/Tk off): >> None work - I get error messages about plD_dispatch_init_wingcc and >> the like. > > Probably we should wait to deal with this issue until 2 is solved. > Well, let us see how fast we can it. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-18 06:20:28
|
Hi, > I have: > > bash-3.1$ gcc --version > gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > bash-3.1$ g++ --version > g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Same for me here on a newly installed cygwin environment (since my hard disc crashed :() Werner |
From: Alan W. I. <ir...@be...> - 2006-08-18 12:53:32
|
On 2006-08-18 06:40+0200 Arjen Markus wrote: >>> 3. Enabling all drivers, shared libraries off: >>> Complaints from the compiler (gcc) about tkwin.c: >>> a parse error (if I remember correctly) about "nmemb" at >>> line 1823. >> >> Please give the exact error message (with a lot of surrounding context) >> and not a paraphrase. > Using the following command-line (left all drivers on by mistake): > > /cygdrive/c/arjen/cmake-cygwin/CMake/bin/cmake -DBUILD_TEST:BOOL=ON > -DBUILD_SHARED_LIBS:BOOL=OFF -DDEFAULT_NO_DEVICES:BOOL=OFF -DPLD_ps:BOOL=ON > -G "Unix Makefiles" ../plplot > > in the build directory I get (from make): > > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1823: error: > parse error before "nmemb" > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c: In function > `ckcalloc': > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: > `size' undeclared (first use in this function) > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: > (Each undeclared identifier is reported only once > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: for > each function it appears in.) > /cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.c:1826: error: > `nmemb' undeclared (first use in this function) > make[2]: *** > [src/CMakeFiles/plplotd.dir/cygdrive/c/arjen/plplot-5.6.1-cmake/plplot/drivers/tkwin.o] Error 1 > make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 > make: *** [all] Error 2 I am not much of a C expert, but the original author of the tkwin device (Vince Darley who may be lurking on list here) was obviously trying to do a horrible hack of all the memory management stuff with a bunch of #undef's and #defs near the front of this file. This fragile mess works on Linux and some forms of windows, but obviously not on your version of Cygwin. Anyhow, this seems a tough problem to me so I suggest you bypass this for now with -DPLD_tkwin=OFF on Cygwin. I don't know what to say regarding the other Cygwin problems you encountered. Your C++ problem cannot be replicated by Werner so I encourage you to replicate how he has installed his Cygwin tool chain. With regard to the lt_dlinit() problem, I still need the details I asked for to make further progress. 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-18 13:05:06
|
Alan W. Irwin wrote: > > I am not much of a C expert, but the original author of the tkwin device > (Vince Darley who may be lurking on list here) was obviously trying to > do a > horrible hack of all the memory management stuff with a bunch of #undef's > and #defs near the front of this file. This fragile mess works on > Linux and > some forms of windows, but obviously not on your version of Cygwin. > Anyhow, > this seems a tough problem to me so I suggest you bypass this for now > with > -DPLD_tkwin=OFF on Cygwin. I will do that. > > I don't know what to say regarding the other Cygwin problems you > encountered. Your C++ problem cannot be replicated by Werner so I > encourage > you to replicate how he has installed his Cygwin tool chain. With regard > to the lt_dlinit() problem, I still need the details I asked for to make > further progress. I misread your earlier reply, I will send you the information as soon as possible (not sure when that will be though - busy weekend and busy week ahead). As for the C++ problem, he seems to have the same versions as I have. Perhaps inspecting the generated makefiles will give a hint of the solution or the cause. (The makefiles are relatively simple - if you compare them to the involved ones generated by the autotools ...) Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-18 05:50:57
|
>> However: >> C++ failed, the linker complained about plstream::plinit and the >> like. > > Werner do you have this Cygwin issue? I don't recall whether > you use the gcc tool chain or not. No, no c++ problems here - using cygwin cmake and gmake and gcc/g++ toolchain. Werner |
From: Arjen M. <arj...@wl...> - 2006-08-18 07:11:20
|
Werner Smekal wrote: > >>> However: >>> C++ failed, the linker complained about plstream::plinit and the >>> like. >> >> >> Werner do you have this Cygwin issue? I don't recall whether >> you use the gcc tool chain or not. > > > > No, no c++ problems here - using cygwin cmake and gmake and gcc/g++ > toolchain. > > Werner > Well, it could be that my Cygwin installation is too minimal - I have tried to keep it minimal to see what is needed. In the ABS we configure libtool explicitly - maybe that is not being done for the CBS? (I think that is the reason for an earlier failure regarding the examples too - pkg-config was missing from my installation and with the ABS that is configured as well). Anyway, I have updated the examples according to your suggestions. Could you test them, Werner? Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-18 13:07:59
|
On 2006-08-18 09:11+0200 Arjen Markus wrote: > Anyway, I have updated the examples according to your suggestions. Could > you test them, Werner? Arjen, the whole point was for you to test the suggested changes for your bare windows tool chain before your commit, but you obviously got distracted by your Cygwin troubles. Anyhow, will you please test the changed examples on bare windows? In particular, I have been concerned (for several days now) with inconsistencies between nan.h and x21c.c (and now x21c.cc). For example #if defined(_WIN32) && defined(_MSC_VER) should be changed to #if defined(_WIN32) && defined(_MSC_VER) && _MSC_VER == 600 to be consistent with nan.h. Please test and commit at least that change for x21c.c and x21c.cc. Also, there is an open question about whether you have to put #include <float.h> #include <ymath.h> within the #if defined(_WIN32) && defined(_MSC_VER) && _MSC_VER == 600 block in the examples to be consistent with nan.h. Your tests should resolve whether those #includes are necessary or not. Anyhow, I look forward to your definitive, tested commits so that we can move on to other issues. 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-18 13:20:12
|
Alan W. Irwin wrote: > On 2006-08-18 09:11+0200 Arjen Markus wrote: > >> Anyway, I have updated the examples according to your suggestions. Could >> you test them, Werner? > > > Arjen, the whole point was for you to test the suggested changes for your > bare windows tool chain before your commit, but you obviously got > distracted > by your Cygwin troubles. Anyhow, will you please test the changed > examples > on bare windows? > > In particular, I have been concerned (for several days now) with > inconsistencies between nan.h and x21c.c (and now x21c.cc). > > For example > > #if defined(_WIN32) && defined(_MSC_VER) > should be changed to #if defined(_WIN32) && defined(_MSC_VER) && > _MSC_VER == 600 > > to be consistent with nan.h. > > Please test and commit at least that change for x21c.c and x21c.cc. > > Also, there is an open question about whether you have to put > > #include <float.h> > #include <ymath.h> > > within the #if defined(_WIN32) && defined(_MSC_VER) && _MSC_VER == 600 > block in the examples to be consistent with nan.h. Your tests should > resolve > whether those #includes are necessary or not. > > Anyhow, I look forward to your definitive, tested commits so that we can > move on to other issues. Alan, you are quite right: ironing out these issues on bare Windows should be solved first. I will concentrate on those. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-16 06:26:48
|
Hi, these changes somehow break the Visual C++ 2005 build: my commands: * cd plplot * mkdir buildnmake * cd buildnmake * cmake -G "NMake Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=plplot_install -DwxWidgets_ROOT_DIR=%WXWIN% -DwxWidgets_LIB_DIR=%WXWIN%\lib\vc_dll -DwxWidgets_USE_REL_AND_DBG=FALSE -DBUILD_SHARED_LIBS=OFF -DBUILD_TEST=ON -DwxWidgets_USE_MONOLITHIC=ON .. * nmake but it stops with an error in plggrid.c [ 30%] Building C object src/CMakeFiles/plplotd.dir/plgridd.obj C:\PROGRA~1\MICROS~4\VC\bin\cl.exe @C:\DOKUME~1\smekal\LOKALE~1\Temp\nm 42F.tmp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl /DWIN32 /D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IC:\DevZo ne\plplot\include -IC:\DevZone\plplot\buildnmake -IC:\DevZone\plplot\buildnmake\ include -DHAVE_CONFIG_H /Fosrc/CMakeFiles/plplotd.dir/plgridd.obj /FdC:\DevZon e\plplot\buildnmake\src\plplotd.pdb -c C:\DevZone\plplot\src\plgridd.c plgridd.c C:\DevZone\plplot\src\plgridd.c(304) : error C2039: '_D' : is not a member of '_ Dconst' C:\Programme\Microsoft Visual Studio 8\VC\INCLUDE\ymath.h(30) : see decl aration of '_Dconst' C:\DevZone\plplot\src\plgridd.c(347) : error C2039: '_D' : is not a member of '_ Dconst' C:\Programme\Microsoft Visual Studio 8\VC\INCLUDE\ymath.h(30) : see decl aration of '_Dconst' C:\DevZone\plplot\src\plgridd.c(362) : error C2039: '_D' : is not a member of '_ Dconst' C:\Programme\Microsoft Visual Studio 8\VC\INCLUDE\ymath.h(30) : see decl aration of '_Dconst' C:\DevZone\plplot\src\plgridd.c(492) : error C2039: '_D' : is not a member of '_ Dconst' C:\Programme\Microsoft Visual Studio 8\VC\INCLUDE\ymath.h(30) : see decl aration of '_Dconst' NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~4\VC\bin\cl.exe' : return code '0 x2' Stop. NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake .exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake .exe"' : return code '0x2' Stop. In line 304, 347 "NaN" is used .... regards, Werner Alan W. Irwin wrote: > On 2006-08-15 15:18-0700 Alan W. Irwin wrote: > >> For the life of me I cannot see why that change is necessary. All that >> nan.h does is #define NaN... > > Oops. Actually, that was the old nan.h. I see now that the new one does > > #define isnan _isnan > > in the bare windows case and this is obviously needed for example 21. > > To make our life a bit simpler I have just made the additional change of > replacing > > #include "nan.h" > > by > > #if defined(_WIN32) && defined(_MSC_VER) > #define isnan _isnan > #endif > > in x21c.c. > > Then we don't have to worry about adding the extra -I option to find nan.h > in the build tree, and we don't have to install nan.h so that the installed > examples work. > > Please test that my change works for you. In particular I wasn't sure > whether > > #include <float.h> > #include <ymath.h> > > were needed or not to determine _isnan. Please put them in if they are > needed. > > 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 > __________________________ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Werner S. <sm...@ia...> - 2006-08-16 11:16:14
|
Hi, I made the latest plplot code compile with Visual C++ 2005 using nmake makefiles (static build) together with the wxwidgets and wingcc drivers (and some others). Here are the necessary commands: * cd plplot * mkdir buildnmake * cd buildnmake * cmake -G "NMake Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=plplot_install -DBUILD_SHARED_LIBS=OFF -DBUILD_TEST=ON -DwxWidgets_ROOT_DIR=%WXWIN% -DwxWidgets_LIB_DIR=%WXWIN%\lib\vc_dll -DwxWidgets_CONFIGURATION=mswd -DwxWidgets_USE_REL_AND_DBG=FALSE -DwxWidgets_USE_MONOLITHIC=ON .. * nmake * cd examples * copy %WXWIN%\lib\vc_dll\wxmsw26d_vc_custom.dll . * copy ..\..\..\data\*.fnt . * x01c.exe * .... I use a shared/monolithic/debug wxWidgets library (nmake -f makefile.vc SHARED=1 MONOLOTHIC=1 BUILD=debug). It compiles all samples until x21c.c where the problem with the unknown reference to _isnan arises. I had to make the following changes though: 1) I added $ENV{LIB} to the paths in FindGDI32.cmake, in order gdi32.lib is found for MSDEV environment, i.e. find_library( GDI32_LIBRARY NAMES gdi32 PATHS ${GDI32_LIBRARY_DIRS} $ENV{LIB} NO_SYSTEM_ENVIRONMENT_PATH ) 2) In example x17c.c I replaced errcode with pl_errcode, since errcode is somehow already defined in Visual C++ 2005 (its just a local variable, so this should be no problem). 3) In wxwidgets.cmake I removed the check for ENABLE_DYNDRIVERS, since I doesn't see the necessity for this - the wxwidgets driver should also work in static build (and actually does work). Problems may arise, if the wxWidgets library is static, but this we have to test. Alan, could you please make these changes? Here is also the CMake summary: Important CMake results: CMAKE_SYSTEM_NAME: Windows SWIG_FOUND: 0 PERL_FOUND: YES X11_FOUND: CMAKE_INSTALL_PREFIX: C:/DevZone/plplot/buildnmake/plplot_install CMAKE_BUILD_TYPE: Debug CMAKE_C_COMPILER CMAKE_C_FLAGS: C:/Programme/Microsoft Visual St udio 8/VC/bin/cl.exe /DWIN32 /D_WINDOWS /W3 /Zm1000 CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS: C:/Programme/Microsoft Visual St udio 8/VC/bin/cl.exe /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR LIB_TAG: d ENABLE_DYNDRIVERS: OFF DEVICES_LIST: hp7470;hp7580;lj_hpgl;mem;null;pbm;plmeta;ps;wingcc;wxwidgets;xfig DRIVERS_LIST: hpgl;mem;null;pbm;plmeta;ps;wingcc;wxwidgets;xfig Library options: BUILD_SHARED_LIBS: OFF PL_DOUBLE: ON Optional libraries: HAVE_QHULL: OFF WITH_CSA: OFF HAVE_FREETYPE: HAVE_PTHREAD: Language Bindings: ENABLE_f77: OFF ENABLE_f95: OFF ENABLE_cxx: ON ENABLE_java: OFF ENABLE_python: OFF ENABLE_octave: ENABLE_tcl: OFF ENABLE_itcl: OFF ENABLE_tk: OFF ENABLE_itk: OFF ENABLE_pdl: OFF As you can see, wingcc, wxwidgets are available and also working (apart from the wingcc bugs). Here is also the error report for the x21c.c example plplotd.lib(plgridd.obj) : error LNK2019: unresolved external symbol _isnan refe renced in function _grid_nnli x21c.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~4\VC\bin\cl.exe' : return code '0 x2' Stop. NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake .exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Programme\Microsoft Visual Studio 8\VC\BIN\nmake .exe"' : return code '0x2' Stop. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-16 15:45:08
|
Hi Werner: Due to time zone differences I am responding rather late to your requests. Comments and questions for you and Arjen below.... Alan On 2006-08-16 13:15+0200 Werner Smekal wrote: > It compiles all samples until x21c.c where the problem with the unknown > reference to _isnan arises. Arjen, will you be responsible for making the required change? I think you will now need a && _MSC_VER == 600, and you may have to add one or two #includes to make it consistent with the current nan.h. > > I had to make the following changes though: > 1) I added $ENV{LIB} to the paths in FindGDI32.cmake, in order gdi32.lib is > found for MSDEV environment, i.e. > > find_library( > GDI32_LIBRARY > NAMES gdi32 > PATHS ${GDI32_LIBRARY_DIRS} > $ENV{LIB} > NO_SYSTEM_ENVIRONMENT_PATH > ) Werner, what happens if you try instead ... PATHS ${GDI32_LIBRARY_DIRS} ) ? In other words, is LIB honored if you drop NO_SYSTEM_ENVIRONMENT_PATH? My feeling is it is quite unusual to use NO_SYSTEM_ENVIRONMENT_PATH so this may be the fundamental source of your problem. If my suggested form works, let me know and I will make the commit. > 2) In example x17c.c I replaced errcode with pl_errcode, since errcode is > somehow already defined in Visual C++ 2005 (its just a local variable, so > this should be no problem). To avoid name clashes like you just encountered, I have made the errcode ==> pl_errcode change consistently for all versions of example 17. > 3) In wxwidgets.cmake I removed the check for ENABLE_DYNDRIVERS, since I > doesn't see the necessity for this - the wxwidgets driver should also work in > static build (and actually does work). Problems may arise, if the wxWidgets > library is static, but this we have to test. With ENABLE_DYNDRIVERS ON, the device driver code is built into a plug-in with no object code put into libplplot, the core PLplot library. Under these conditions it doesn't matter whether the device drivers are written in C or C++. However, in the special case of ENABLE_DYNDRIVERS OFF, the device driver object code is put into libplplot. This is a C library and mixing in C++ object code causes linking problems on some platforms. So the Unix side policy has always been to disable the C++ devices (psttf, wxwidgets, and presumably win3 when we get that far) when ENABLE_DYNDRIVERS OFF. For Unix platforms this is not a particularly onerous requirement because usually ENABLE_DYNDRIVERS can be set to ON for those platforms. However, it is an onerous requirement in the windows case because I am not sure we can ever get ENABLE_DYNDRIVERS to work for that case so I think we should probably modify the rule in that case. I need input from at least Werner and Arjen on the windows side of things on this issue before making the change, though. For any of the many different windows platforms is mixing C and C++ objects into libplplot going to cause any trouble? Please also comment on the special cases of Cygwin and MinGW (which up to now via autotools always turned psttf and wxwidgets off when dynamic devices were disabled). Let's assume you decide that for Cygwin, MinGW, and all variations of the bare windows platform tool chain you can mix C++ and C objects into the same library. Then as a practical matter I need to know whether WIN32 (documented at http://www.cmake.org/Wiki/CMake_Useful_Variables as being true on windows and Cygwin) is also true on MinGW. (try message("WIN32 = ${WIN32}") on MinGW to find out. If so, then I can simply enclose the current test in if(NOT WIN32) .... endif(NOT WIN32). 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-16 19:43:06
|
Hi Alan, > Werner, what happens if you try instead > ... > PATHS ${GDI32_LIBRARY_DIRS} > ) > > ? This doesn't work, since cmake finds gdi32.dll in the system path, which is not what I want (doesn't make too much sense in my opinion, but ...). Anyway, I found a better way (in my opinion the correct way to check if gdi32.lib is there or not). As far as I can see from the windows compilers I have experimented with (watcom, visual c++, borland c++, mingw, cygwin, digital mars), windows.h and gdi32.lib are always provided by the compiler somewhere in its lib paths, so if the compilers are correctly set up, windows.h and gdi32.lib is just there - you don't need to search for it. Therefore it's better to test if the compiler is set up correctly, by just compiling a test program - this program and the new FindGDI32.cmake are attached. The test program is most minimal it includes windows.h and uses a gd32 function (DPtoLP) - so it won't compile if windows.h or gdi32.lib are missing. No need to set any paths or find anything. I also made some changes to wingcc.cmake, so that it doesn't print libgdi32.a since this is not available for visual c++. I tested this module for Visual C++ 2005, cygwin and mingw/CLI - all were positive, I also renamed gdi32.lib and than it disabled wingcc. So I think this is the way to go. Please make the appropriate changes if you think this is okay. Thanks, Werner |