From: Alan W. I. <ir...@be...> - 2006-07-27 15:49:48
|
I got a definitive answer on almost all linker and compiler override issues at http://public.kitware.com/pipermail/cmake/2006-July/010334.html. For example, CMAKE_SHARED_LINKER_FLAGS is the "master switch" for all other variations of that variable. (I must say, the guys on that list have been most helpful.) Looking further at CMakeCInformation.cmake and equivalent files for other computer languages I decided to use the CMAKE_USER_MAKE_RULES_OVERRIDE variable instead to lump all special PLplot defaults for compiler and linker rules in one file. Hazen, will you give latest CVS a try with fortran + complete build and test of installed examples? Also, are you game to add the aquaterm driver to the CBS for PLplot following what is done for the other device drivers in cmake/modules? As I think you have alread found out, figuring out things in CMake is pretty straightforward, but of course if you have any questions about adding that driver to CBS, I would be happy to help out. 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-07-28 00:23:37
|
On Jul 27, 2006, at 11:48 AM, Alan W. Irwin wrote: > > Hazen, will you give latest CVS a try with fortran + complete build > and test > of installed examples? Also, are you game to add the aquaterm > driver to the > CBS for PLplot following what is done for the other device drivers in > cmake/modules? As I think you have alread found out, figuring out > things in > CMake is pretty straightforward, but of course if you have any > questions > about adding that driver to CBS, I would be happy to help out. I just tried the latest CVS. The status on my OS-X box is that it works without Fortran or Python. I think might know the source of the python problems. I'm a little more concerned about compiling with Fortran. However, figuring things out in cmake is indeed pretty easy, so I'll see if I can't provide a solution instead of an error log. I compiled the examples by setting BUILD_TEST to ON and they worked as expected. However, when I went to what I assume is the "installed exampled directory", /usr/local/share/plplot5.6.1/examples on my machine, and tried "make" I got: iMac /usr/local/share/plplot5.6.1/examples : make target=`echo all`; \ list='c c++ f77 f95 tk java'; for subdir in $list; do \ if test -d "$subdir"; then \ echo "Making $target in $subdir"; \ (cd $subdir && make $target); \ fi; \ done Making all in c /usr/bin/gcc x01c.c -o x01c `PKG_CONFIG_PATH=/usr/local/lib/ pkgconfig pkg-config --cflags --libs plplotd` /usr/bin/ld: warning can't open dynamic library: libcsirocsa.dylib.0 referenced from: /usr/local/lib/libplplotd.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: warning can't open dynamic library: libcsironn.dylib.0 referenced from: /usr/local/lib/libplplotd.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: Undefined symbols: _csa_addpoints referenced from libplplotd.dylib.9 expected to be defined in libcsirocsa.dylib.0 _csa_approximate_points referenced from libplplotd.dylib.9 expected to be defined in libcsirocsa.dylib.0 _csa_calculatespline referenced from libplplotd.dylib.9 expected to be defined in libcsirocsa.dylib.0 _csa_create referenced from libplplotd.dylib.9 expected to be defined in libcsirocsa.dylib.0 _csa_destroy referenced from libplplotd.dylib.9 expected to be defined in libcsirocsa.dylib.0 _lpi_interpolate_points referenced from libplplotd.dylib.9 expected to be defined in libcsironn.dylib.0 _nn_rule referenced from libplplotd.dylib.9 expected to be defined in libcsironn.dylib.0 _nnpi_interpolate_points referenced from libplplotd.dylib.9 expected to be defined in libcsironn.dylib.0 collect2: ld returned 1 exit status make[1]: *** [x01c] Error 1 I'd guess the problem might have something to do with the absence of pkgconfig on my machine. However, perhaps I did not understand what you meant by installed example directory. The output of the make file doesn't look like what I'd expected from running make in my plplot build directory. I will try and add the aquaterm driver to CBS this weekend. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-07-28 02:01:27
|
On 2006-07-27 20:22-0400 Hazen Babcock wrote: > I just tried the latest CVS. The status on my OS-X box is that it works > without Fortran or Python. I think might know the source of the python > problems. I'm a little more concerned about compiling with Fortran. However, > figuring things out in cmake is indeed pretty easy, so I'll see if I can't > provide a solution instead of an error log. That would be great, Hazen. > > I compiled the examples by setting BUILD_TEST to ON and they worked as > expected. However, when I went to what I assume is the "installed exampled > directory", /usr/local/share/plplot5.6.1/examples on my machine, and tried > "make" I got: > > iMac /usr/local/share/plplot5.6.1/examples : make > target=`echo all`; \ > list='c c++ f77 f95 tk java'; for subdir in $list; do \ > if test -d "$subdir"; then \ > echo "Making $target in $subdir"; \ > (cd $subdir && make $target); \ > fi; \ > done > Making all in c That make result and the directory name are consistent with you being in the examples directory installed by PLplot at some time. Have a look at the creation times of the files to make sure they correspond to your most recent install. > /usr/bin/gcc x01c.c -o x01c `PKG_CONFIG_PATH=/usr/local/lib/pkgconfig > pkg-config --cflags --libs plplotd` > /usr/bin/ld: warning can't open dynamic library: libcsirocsa.dylib.0 > referenced from: /usr/local/lib/libplplotd.dylib (checking for undefined > symbols may be affected) (No such file or directory, errno = 2) > /usr/bin/ld: warning can't open dynamic library: libcsironn.dylib.0 > referenced from: /usr/local/lib/libplplotd.dylib (checking for undefined > symbols may be affected) (No such file or directory, errno = 2) > /usr/bin/ld: Undefined symbols: > _csa_addpoints referenced from libplplotd.dylib.9 expected to be defined in > libcsirocsa.dylib.0 > _csa_approximate_points referenced from libplplotd.dylib.9 expected to be > defined in libcsirocsa.dylib.0 > _csa_calculatespline referenced from libplplotd.dylib.9 expected to be > defined in libcsirocsa.dylib.0 > _csa_create referenced from libplplotd.dylib.9 expected to be defined in > libcsirocsa.dylib.0 > _csa_destroy referenced from libplplotd.dylib.9 expected to be defined in > libcsirocsa.dylib.0 > _lpi_interpolate_points referenced from libplplotd.dylib.9 expected to be > defined in libcsironn.dylib.0 > _nn_rule referenced from libplplotd.dylib.9 expected to be defined in > libcsironn.dylib.0 > _nnpi_interpolate_points referenced from libplplotd.dylib.9 expected to be > defined in libcsironn.dylib.0 > collect2: ld returned 1 exit status > make[1]: *** [x01c] Error 1 Here is my corresponding make result for just one installed C example cd c touch x01c.c make x01c /usr/bin/gcc x01c.c -o x01c -Wl,-rpath -Wl,/home/software/plplot_cvs/installcmake/lib `PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig pkg-config --cflags --libs plplot` When I execute the pkg-config command independently (without the surrounding back quotes), here are my results. software@starling> PKG_CONFIG_PATH=/home/software/plplot_cvs/installcmake/lib/pkgconfig \ pkg-config --cflags --libs plplotd -I/home/software/plplot_cvs/installcmake/include/plplot /home/software/autotools/install/lib/libltdl.so /usr/lib/libdl.so -L/home/software/plplot_cvs/installcmake/lib -lplplotd The RPATHCMD variable in my c directory Makefile is set to RPATHCMD = -Wl,-rpath -Wl,/home/software/plplot_cvs/installcmake/lib This is what you expect. That value is set in cmake/modules/rpath.cmake with set(RPATHCMD "-Wl,-rpath -Wl,${LIB_DIR}"), and LIB_DIR is $prefix/lib which translates to /home/software/plplot_cvs/installcmake/lib in my case. To make more sense of your results above, could you please give the results of PKG_CONFIG_PATH=/usr/local/lib/pkgconfig pkg-config --cflags --libs plplotd (the same command your make command executed above without the enclosing back quote marks). Also, could you please give the value of RPATHCMD in you installed c directory Makefile? I see no sign of the -Wl,-rpath -Wl options in your results above so I suspect RPATHCMD is blank in your case. The question is why? Perhaps you are in an old installed PLplot examples tree that has nothing to do with CMake? > I'd guess the problem might have something to do with the absence of > pkgconfig on my machine. It is hard to tell because you have such a generic install prefix (/usr/local) so I don't know whether pkg-config is helping you to find that directory or whether it is found by default. To get rid of this ambiguity could you change your install prefix to a path specific to plplot such as /usr/local/plplot or $HOME/plplot/install? (Also, if you have a special install tree, it is easy to remove it to get a fresh start without interfering with anything else.) In any case, I suggest you install pkg-config if you don't have it. > I will try and add the aquaterm driver to CBS this weekend. Thanks, Hazen. 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-01 01:49:09
|
On Jul 27, 2006, at 10:01 PM, Alan W. Irwin wrote: > >> I will try and add the aquaterm driver to CBS this weekend. > > Thanks, Hazen. I'm working on adding the aquaterm driver to cmake and I have a question. Basically I'm puzzled about where PLD_aqt gets set to "OFF". I uncommented the line "aqt:aqt:on" in cmake/modules/drivers- init.cmake and then I added a bunch of MESSAGE statements to cmake/ modules/drivers.cmake so that I could see what is happening to PLD_aqt, and also PLD_png for comparison. It seems that as soon as cmake enters/executes drivers.cmake PLD_aqt is "OFF" and PLD_png is "ON". However, as I understand the flow, none of the checks for these drivers has been done. I imagine that there must be some file upstream of drivers.cmake and downstream of config.h.cmake that is responsible for this action but I don't understand the layout of our cmake system well enough to find this file (and I also couldn't find it by grepping for PLD in the obvious directories or searching for "aqt" in recent cvs commits). thanks, -Hazen |
From: Alan W. I. <ir...@be...> - 2006-08-01 03:16:20
|
On 2006-07-31 21:48-0400 Hazen Babcock wrote: > > On Jul 27, 2006, at 10:01 PM, Alan W. Irwin wrote: >> >>> I will try and add the aquaterm driver to CBS this weekend. >> >> Thanks, Hazen. > > I'm working on adding the aquaterm driver to cmake and I have a question. > Basically I'm puzzled about where PLD_aqt gets set to "OFF". I uncommented > the line "aqt:aqt:on" in cmake/modules/drivers-init.cmake and then I added a > bunch of MESSAGE statements to cmake/modules/drivers.cmake so that I could > see what is happening to PLD_aqt, and also PLD_png for comparison. It seems > that as soon as cmake enters/executes drivers.cmake PLD_aqt is "OFF" and > PLD_png is "ON". However, as I understand the flow, none of the checks for > these drivers has been done. I imagine that there must be some file upstream > of drivers.cmake and downstream of config.h.cmake that is responsible for > this action but I don't understand the layout of our cmake system well enough > to find this file (and I also couldn't find it by grepping for PLD in the > obvious directories or searching for "aqt" in recent cvs commits). Lets take the working png case first. "png:gd:ON" (that upper case is important) is part of the DRIVERS_DEVICE_LIST definition which each element of the list being a colon-separated triplet string as above. That list is parsed in the foreach loop at the end of cmake/modules/drivers-init.cmake with some complications concerning whether PRESET_DEFAULT is set or not which you don't have to worry about since normally there is no PRESET_DEFAULT that applies uniformly to all devices. Ultimately it is option(PLD_${DEVICE} "Enable ${DEVICE} device" ${DEFAULT}) in the loop that sets the _default_ (ON or OFF) value for each device in the list. Because of the "ON" in "png:gd:ON", PLD_png defaults to ON. At this point you should probably review "cmake --help-full |less" (I have that command going all the time) to be clear on everything that happens in drivers-init.cmake to put the initial setting of PLD_png into the cache via the above option statement. Now, if you look at drivers.cmake, you will see that after drivers-init.cmake is included, then gd.cmake is included as well. If gd.cmake determines that some necessary system resources are missing so that device png cannot be built, then the cached value of PLD_png is forced to OFF no matter what the user does. So here are the steps for a new (to cmake) device such as aqt. 1. Uncomment "aqt:aqt:ON" in drivers-init.cmake. I also suggest you change the default from ON to OFF and use -DPLD_PNG=ON to test your cmake implementation until you are confident enough of that implementation that you want everybody to use it by default. 2. Uncomment include(aqt) in drivers.cmake. 3. Create an aqt.cmake file that actually does all the nitty-gritty of looking for system resources required for that device and determining variables corresponding to the ones filled in for the gd.cmake case i.e., # PLD_aqt - ON means the aqt device is enabled # aqt_COMPILE_FLAGS - COMPILE_FLAGS required to compile aqt device driver. # aqt_LINK_FLAGS - LINK_FLAGS for dynamic aqt device driver. # DRIVERS_LINK_FLAGS - list of LINK_FLAGS for all static device drivers. If you stick with that exact spelling of those variables, then everything else device related should just work. The first variable is (as we have seen) the individual device flag where there may be more than one per device driver (see PLD_png, PLD_jpeg, PLD_gif in gd.cmake). The remaining three variables are related to the device driver (aqt in your case and gd in the gd.cmake case). I hope this discussion has clarified how the PLplot devices are handled in our CBS and please feel free to ask more questions as needed. Good luck with the remainder of your CMake implementation for aqt. 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-01 19:49:42
|
On 2006-07-31 20:14-0700 Alan W. Irwin wrote: > So here are the steps for a new (to cmake) device such as aqt. If you look at my most recent commit message on the plplot-cvs list, you will see all these steps done for a simple case (the cgm device driver which now builds, runs, and gives good-looking results with our CBS). Note FindCD.cmake follow the standards for FindXXX.cmake module files given by the share/CMake/Modules/readme.txt file. Here is the current status of the complete list of device drivers that are not yet implemented for our CBS. linuxvga: Alan (I plan to do this today) wxwidgets: Werner aqt: Hazen gnome: permanently retired (since it is unmaintained and superseded by gcw). tk, tkwin, ntk: waiting for Tcl/Tk interface to be implemented wingcc: needs windows-savvy volunteer sys/win32/msdev/src/win3: needs windows-savvy volunteer 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-07 10:22:36
Attachments:
wingcc.cmake
FindGDI32.cmake
|
Hi list, Alan W. Irwin wrote: > wingcc: needs windows-savvy volunteer I'm actually working on the wxwidgets-cmake stuff, but I thought I can do wingcc as well (looked easier :). Anyway, attached are two files wingcc.cmake FindGDI32.cmake which should go into cmake/modules. If you activate the driver in drivers.cmake it works ok for the MinGW/Windows CLI combination. Didn't try MinGW/MSys combination. I think wingcc can savely be turned on, since cmake won't find windows.h/gdi32.dll on any other platform. Alan, could you have a quick look at the files if they fit into the CBS and commit them if so? The FindGDI32.cmake will only work for the MinGW/CLI combination (very likely also for MinGW/msys). Are there other compilers also well which should support this driver? Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-08-07 15:22:49
|
On 2006-08-07 12:21+0200 Werner Smekal wrote: > Hi list, > > Alan W. Irwin wrote: > >> wingcc: needs windows-savvy volunteer > > I'm actually working on the wxwidgets-cmake stuff, but I thought I can do > wingcc as well (looked easier :). Anyway, attached are two files > > wingcc.cmake > FindGDI32.cmake > > which should go into cmake/modules. If you activate the driver in > drivers.cmake it works ok for the MinGW/Windows CLI combination. Didn't try > MinGW/MSys combination. I think wingcc can savely be turned on, since cmake > won't find windows.h/gdi32.dll on any other platform. > > Alan, could you have a quick look at the files if they fit into the CBS and > commit them if so? Done, with a change to add an overall message about the check and default PLD_wingcc ON. Thanks very much, Werner, for this contribution to our CBS. Arjen, and Andrew (Roach), could you check this device driver builds and works properly with our CBS on all the platforms accessible to you? One acknowledged weak point is the ability to find the library directory so in time you may want to update that section of FindGDI32.cmake. 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-07 15:34:13
|
Hi list, I also tried the MinGW/msys combination and it worked also ok. Though I should mention, that the wingcc driver seems to be buggy, since sometimes (didn't find out how and when, but very often) it shows the plot just for a short time and than blanks the screen. As far as I remember, this was already mentioned in the mailing list, but I couldn't find the email in question. But I don't think this is a CBS problem. Regards, Werner Alan W. Irwin wrote: > On 2006-08-07 12:21+0200 Werner Smekal wrote: > >> Hi list, >> >> Alan W. Irwin wrote: >> >>> wingcc: needs windows-savvy volunteer >> I'm actually working on the wxwidgets-cmake stuff, but I thought I can do >> wingcc as well (looked easier :). Anyway, attached are two files >> >> wingcc.cmake >> FindGDI32.cmake >> >> which should go into cmake/modules. If you activate the driver in >> drivers.cmake it works ok for the MinGW/Windows CLI combination. Didn't try >> MinGW/MSys combination. I think wingcc can savely be turned on, since cmake >> won't find windows.h/gdi32.dll on any other platform. >> >> Alan, could you have a quick look at the files if they fit into the CBS and >> commit them if so? > > Done, with a change to add an overall message about the check and default > PLD_wingcc ON. Thanks very much, Werner, for this contribution to our CBS. > Arjen, and Andrew (Roach), could you check this device driver builds and > works properly with our CBS on all the platforms accessible to you? One > acknowledged weak point is the ability to find the library directory so in > time you may want to update that section of FindGDI32.cmake. > > Alan -- Werner Smekal email: sm...@ia... phone: +43-(0)676-5014479 |
From: Arjen M. <arj...@wl...> - 2006-08-08 06:40:38
|
Werner Smekal wrote: >Hi list, > >I also tried the MinGW/msys combination and it worked also ok. Though I >should mention, that the wingcc driver seems to be buggy, since >sometimes (didn't find out how and when, but very often) it shows the >plot just for a short time and than blanks the screen. > >As far as I remember, this was already mentioned in the mailing list, >but I couldn't find the email in question. > >But I don't think this is a CBS problem. > > Hello Werner, I reported that - I thought I was the only one and as my PC is being used by other members of my household who have less concern of what is being put on it than myself ;), I thought it a consequence of one of those infernal games (I have seen other bizarre phenomena too). In my case, example 1 shows at least something (but incomplete), example 2 shows something very very briefly and the others seem to show only a black window. It definitely worked before, and the source code has not changed as far as I can tell. Hm, this calls for some deeper investigation. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-01 22:42:39
|
On 2006-08-01 12:47-0700 Alan W. Irwin wrote: > linuxvga: Alan (I plan to do this today) Done. It was a trivial CBS exercise but a pretty ugly result so I have disabled this device driver by default. 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: Geoffrey F. <fu...@li...> - 2006-08-02 14:26:54
|
Alan W. Irwin writes: > On 2006-08-01 12:47-0700 Alan W. Irwin wrote: > > linuxvga: Alan (I plan to do this today) > > Done. It was a trivial CBS exercise but a pretty ugly result so I > have disabled this device driver by default. Hmm. FWIW, I have experienced normal looking output from this driver in the past. Although, it's been a looong time... Red Hat really set the world back a few years ago, with revised VT_Switch handling that made it hard for most people to reach the text consoles. But with xmodmap skullduggery, there do appear to be accessible techniques for defeating the default RedHat bindings. Anyway, I'm not keen on actually throwing linxvga away entirely, but do agree that it is best to disable by default, devices that aren't working correctly, pending reparation by anybody (identified or not) with inclination. |