From: Maurice L. <mj...@ga...> - 2002-08-04 06:00:46
|
From a vanilla checkout & configure, with dyndrivers, Linux RH7.3: $ make install make: *** No rule to make target `libplplottcltk', needed by `xwin_drv'. Stop. No idea. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-08-04 16:37:12
|
Maurice, I cannot reproduce the install bug you reported below. In fact, all your changes are working well here. To be specific I did a vanilla checkout (with all your recent changes) and ./configure --prefix=/usr/local/plplot --enable-dyndrivers \ --enable-java --enable-gnome --enable-ntk --enable-tkwin make no build problems except the usual python warnings. Also, some quick checks of -dev tk; -dev tkwin; -dev xwin; pltcl with tcldemos.tcl; plserver with both tkdemos.tcl and runAllDemos.tcl; and wish with runAllDemos.tcl worked fine. Also, I did some nm tests between libplplottcltk.so and drivers/xwin_drv.so to make sure there were no cross-dependencies. Thus, all your recent changes seem to be working fine. I did make install and unlike the case for your RH7.3 system there were no problems at all. I assume you have looked at Makefile on your RH system? Here, I have SO = .so xwin_drv: shared/xwin$O $(TCLLIB_SO) where TCLLIB_SO = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG)$(SO) and eventually TCLLIB_SO = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG).so.$(SOVERSION) where lib_sh_library.in is overriding the pkg_tcl.in definition. If your RH7.3 Makefile is the same as mine, then from your results below, the RH7.3 make command has ignored the second definition and used the first definition instead with SO undefined. That would be a really strange result so I suspect your Makefile is somehow different from the above. Wild guess to explain all this: on RH7.3 the linux system is somehow not being recognized properly so lib_sh_linux.in is not being included as part of the Makefile? Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Sun, 4 Aug 2002, Maurice LeBrun wrote: > >From a vanilla checkout & configure, with dyndrivers, Linux RH7.3: > > $ make install > make: *** No rule to make target `libplplottcltk', needed by `xwin_drv'. > Stop. > > No idea. > > -- > Maurice LeBrun mj...@ga... > Research Organization for Information Science and Technology of Japan (RIST) > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Maurice L. <mj...@ga...> - 2002-08-05 05:49:53
|
Alan W. Irwin writes: > Maurice, I cannot reproduce the install bug you reported below. > > In fact, all your changes are working well here. > > To be specific I did a vanilla checkout (with all your recent changes) > and > > ./configure --prefix=/usr/local/plplot --enable-dyndrivers \ > --enable-java --enable-gnome --enable-ntk --enable-tkwin I suspect the problem's with the --enable-tkwin. Try --enable-tk instead. I was also surprised to find the following dependencies with the tkwin stuff: gcc -fPIC -c -g -O -I. -I/home/mjl/gts/include -c plplotter.c -o shared/plplotter.o In file included from plplotter.c:276: /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory Ugh. More internal TK headers that I need to remember to install I see. (I already have several non-standard ones installed, sigh.) -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-08-05 05:59:55
|
Maurice LeBrun writes: > I was also surprised to find the following dependencies with the tkwin stuff: > > gcc -fPIC -c -g -O -I. -I/home/mjl/gts/include -c plplotter.c -o > shared/plplotter.o > In file included from plplotter.c:276: > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory > > Ugh. More internal TK headers that I need to remember to install I see. > (I already have several non-standard ones installed, sigh.) After copying these two, now: In file included from /home/mjl/gts.tst/include/tkInt.h:27, from plplotter.c:276: /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory make[1]: *** [shared/plplotter.o] Error 1 tkUnixPort.h? This is getting pretty gross. Does anyone have a complete list of all the tk headers one needs to install? -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-08-05 06:18:53
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > I was also surprised to find the following dependencies with the tkwin stuff: > > > > gcc -fPIC -c -g -O -I. -I/home/mjl/gts/include -c plplotter.c -o > > shared/plplotter.o > > In file included from plplotter.c:276: > > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory > > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory > > > > Ugh. More internal TK headers that I need to remember to install I see. > > (I already have several non-standard ones installed, sigh.) > > After copying these two, now: > > In file included from /home/mjl/gts.tst/include/tkInt.h:27, > from plplotter.c:276: > /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory > make[1]: *** [shared/plplotter.o] Error 1 > > tkUnixPort.h? This is getting pretty gross. Does anyone have a complete list > of all the tk headers one needs to install? BTW just for future reference, the culprit in plplotter.c responsible for all this nonsense is: PlPlotterKeyEH(ClientData clientData, register XEvent *eventPtr) { ... string = TkpGetString((TkWindow*)tkwin,eventPtr,&ds); where TkWindow is defined in tkInt.h. So, is there really no workaround that goes through the public API? -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Vince D. <vi...@sa...> - 2002-08-05 13:21:58
|
dbug_enter("PlPlotterKeyEH"); string = TkpGetString((TkWindow*)tkwin,eventPtr,&ds); pldebug("PlPlotterKeyEH", "Translation: %s\n", string); keysym = TkStringToKeysym(string); there are actually two functions which are problematic. I think the exact same effect can be accomplished in pure Tcl (8.3 or newer where 'event generate ... -warp exists), and that this function could be removed completely. Unfortunately it won't be just a couple of lines of Tcl, but not too bad. -- Vince <http://www.santafe.edu/~vince> On Mon, 5 Aug 2002, Maurice LeBrun wrote: > Maurice LeBrun writes: > > Maurice LeBrun writes: > > > I was also surprised to find the following dependencies with the tkwin stuff: > > > > > > gcc -fPIC -c -g -O -I. -I/home/mjl/gts/include -c plplotter.c -o > > > shared/plplotter.o > > > In file included from plplotter.c:276: > > > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory > > > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory > > > > > > Ugh. More internal TK headers that I need to remember to install I see. > > > (I already have several non-standard ones installed, sigh.) > > > > After copying these two, now: > > > > In file included from /home/mjl/gts.tst/include/tkInt.h:27, > > from plplotter.c:276: > > /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory > > make[1]: *** [shared/plplotter.o] Error 1 > > > > tkUnixPort.h? This is getting pretty gross. Does anyone have a complete list > > of all the tk headers one needs to install? > > BTW just for future reference, the culprit in plplotter.c responsible for all > this nonsense is: > > PlPlotterKeyEH(ClientData clientData, register XEvent *eventPtr) > { > ... > string = TkpGetString((TkWindow*)tkwin,eventPtr,&ds); > > where TkWindow is defined in tkInt.h. > > So, is there really no workaround that goes through the public API? > > -- > Maurice LeBrun mj...@ga... > Research Organization for Information Science and Technology of Japan (RIST) > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Vince D. <vi...@sa...> - 2002-08-05 13:38:04
|
Try adding this to the end of pldefaults.tcl: proc plw_moveCursor {w x y xd yd} { incr x $xd incr y $yd event generate $w <Motion> -warp 1 -x $x -y $y } foreach combo { {} Shift Option Control {Shift Option} {Shift Control} {Option Control} {Shift Option Control} } { set multiply 1 for {set i 0} {$i < [llength $combo]} {incr i} { set multiply [expr {$multiply * 5}] } if {[llength $combo]} { set prefix "[join $combo -]-" } else { set prefix "" } foreach dir {Left Right Up Down} x {-1 1 0 0} y {0 0 -1 1} { bind Plframe <${prefix}$dir> "plw_moveCursor %W %x %y\ [expr {$x * $multiply}] [expr {$y * $multiply}]" } } and see if that gets the effect you want. If so, you can happily remove the entire key-event processing stuff from plplotter.c (which I've just discovered doesn't seem to work on win/mac anyway, so this solution is better!) cheers, -- Vince <http://www.santafe.edu/~vince> |
From: Vince D. <vi...@sa...> - 2002-08-05 14:12:44
|
I took it upon my self the test this, and it all works fine (for me!) so I've committed a version of plplotter.c which removes all that tkInt stuff..., plus the appropriate changes elsewhere. cheers, -- Vince <http://www.santafe.edu/~vince> On Mon, 5 Aug 2002, Vince Darley wrote: > Try adding this to the end of pldefaults.tcl: > > proc plw_moveCursor {w x y xd yd} { > incr x $xd > incr y $yd > event generate $w <Motion> -warp 1 -x $x -y $y > } > > foreach combo { > {} > Shift Option Control > {Shift Option} {Shift Control} {Option Control} > {Shift Option Control} > } { > set multiply 1 > for {set i 0} {$i < [llength $combo]} {incr i} { > set multiply [expr {$multiply * 5}] > } > if {[llength $combo]} { > set prefix "[join $combo -]-" > } else { > set prefix "" > } > foreach dir {Left Right Up Down} x {-1 1 0 0} y {0 0 -1 1} { > bind Plframe <${prefix}$dir> "plw_moveCursor %W %x %y\ > [expr {$x * $multiply}] [expr {$y * $multiply}]" > } > } > > and see if that gets the effect you want. If so, you can happily remove > the entire key-event processing stuff from plplotter.c (which I've just > discovered doesn't seem to work on win/mac anyway, so this solution is > better!) > > cheers, > > -- Vince > > <http://www.santafe.edu/~vince> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2002-08-05 16:31:32
|
On Mon, 5 Aug 2002, Vince Darley wrote: > I took it upon my self the test this, and it all works fine (for me!) so > I've committed a version of plplotter.c which removes all that tkInt > stuff..., plus the appropriate changes elsewhere. Thanks very much for getting rid of that dependence on tkInt. However, there is some more work to do because your changed version no longer builds on Linux. I think the first message is the fatal one, but some of those warnings may be serious as well. gcc -fPIC -c -O -I. -I/usr/include/tcl8.3/ -c plplotter.c -o shared/plplotter.o plplotter.c:440: conflicting types for `plPlotterCmd' plplot/plserver.h:41: previous declaration of `plPlotterCmd' plplotter.c: In function `plPlotterCmd': plplotter.c:536: warning: passing arg 3 of `Tk_CreateWindowFromPath' discards qualifiers from pointer target type plplotter.c:549: warning: passing arg 3 of `Tcl_CreateCommand' from incompatible pointer type plplotter.c: In function `PlPlotterWidgetCmd': plplotter.c:693: warning: passing arg 5 of `Tk_ConfigureValue' discards qualifiers from pointer target type plplotter.c:701: warning: passing arg 5 of `Tk_ConfigureInfo' discards qualifiers from pointer target type plplotter.c:821: warning: passing arg 3 of `Tk_GetScrollInfo' from incompatible pointer type plplotter.c:857: warning: passing arg 3 of `Tk_GetScrollInfo' from incompatible pointer type plplotter.c: In function `PlPlotterConfigureEH': plplotter.c:1022: warning: passing arg 2 of `Tcl_EventuallyFree' from incompatible pointer type plplotter.c: In function `Cmd': plplotter.c:1825: warning: passing arg 4 of `plTclCmd' from incompatible pointer type plplotter.c:1914: warning: passing arg 1 of `strtok' discards qualifiers from pointer target type plplotter.c:1941: warning: passing arg 1 of `strtok' discards qualifiers from pointer target type plplotter.c:2027: warning: passing arg 4 of `plTclCmd' from incompatible pointer type plplotter.c: In function `ConfigurePlPlotter': plplotter.c:2118: warning: passing arg 5 of `Tk_ConfigureWidget' from incompatible pointer type plplotter.c: In function `Openlink': plplotter.c:2414: warning: assignment discards qualifiers from pointer target type Alan |
From: Vince D. <vi...@sa...> - 2002-08-05 17:22:19
|
Sorry, fixed the compile problem with tkwin. You will still get some warnings if you're using tk8.3, but they're ok. -- Vince <http://www.santafe.edu/~vince> |
From: Maurice L. <mj...@ga...> - 2002-08-05 07:00:11
|
Maurice LeBrun writes: > Maurice LeBrun writes: > > I was also surprised to find the following dependencies with the tkwin stuff: > > > > gcc -fPIC -c -g -O -I. -I/home/mjl/gts/include -c plplotter.c -o > > shared/plplotter.o > > In file included from plplotter.c:276: > > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory > > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory > > > > Ugh. More internal TK headers that I need to remember to install I see. > > (I already have several non-standard ones installed, sigh.) > > After copying these two, now: > > In file included from /home/mjl/gts.tst/include/tkInt.h:27, > from plplotter.c:276: > /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory > make[1]: *** [shared/plplotter.o] Error 1 > > tkUnixPort.h? This is getting pretty gross. Does anyone have a complete list > of all the tk headers one needs to install? Actually it's worse than just having to install a bunch of non-standard headers. How are we supposed to expect that there's a directory $prefix/unix for holding tkUnixPort.h and the like? This is not good. I guess I'm back to omitting the tkwin driver and trying to fix the install problem. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-08-05 07:19:53
|
Sorry, the make install problem apparently is unrelated to tkwin. Alan W. Irwin writes: > Maurice, I cannot reproduce the install bug you reported below. > ... > I assume you have looked at Makefile on your RH system? Here, I have > > SO = .so > > xwin_drv: shared/xwin$O $(TCLLIB_SO) > > where > > TCLLIB_SO = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG)$(SO) > > and eventually > > TCLLIB_SO = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG).so.$(SOVERSION) > > where lib_sh_library.in is overriding the pkg_tcl.in definition. > > If your RH7.3 Makefile is the same as mine, then from your results below, > the RH7.3 make command has ignored the second definition and used the first > definition instead with SO undefined. That would be a really strange result > so I suspect your Makefile is somehow different from the above. > > Wild guess to explain all this: on RH7.3 the linux system is somehow not > being recognized properly so lib_sh_linux.in is not being included as part > of the Makefile? It's included. For some reason the first definition is being used and not the second. I just commented out the first definition and reran 'make install' and after that the install works fine. Very odd. ged$ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-08-05 08:44:03
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > If your RH7.3 Makefile is the same as mine, then from your results below, > > the RH7.3 make command has ignored the second definition and used the first > > definition instead with SO undefined. That would be a really strange result > > so I suspect your Makefile is somehow different from the above. > > [...] For some reason the first definition is being used and not the > second. I just commented out the first definition and reran 'make install' > and after that the install works fine. Very odd. It's these lines that are the problem: tk_drv: shared/tk$O $(TCLLIB_SO) ... xwin_drv: shared/xwin$O $(TCLLIB_SO) ... Apparently the value of TCLLIB_SO is being filled in, incorrectly, in the first pass through the file. Typically we have dependency lists near the end of the file, by which time all the variables used are correct. So the solution is to either move these later in the file or use a variable that is defined further down. I tested this by changing TCLLIB_SO to TCLLIB_SO_BLAH in both of these lines, then added: TCLLIB_SO_BLAH = $(TCLLIB_SO) as the last line of the makefile. Worked great. I don't know why I'm observing this and no one else is. I even built & tested make-3.79.1 from the tarball, with the same result. So anyway I'll make the change so I can install once again. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-08-05 15:29:27
|
On Mon, 5 Aug 2002, Maurice LeBrun wrote: > It's these lines that are the problem: > > tk_drv: shared/tk$O $(TCLLIB_SO) > ... > > xwin_drv: shared/xwin$O $(TCLLIB_SO) > ... > > Apparently the value of TCLLIB_SO is being filled in, incorrectly, in the > first pass through the file. Typically we have dependency lists near > the end of the file, by which time all the variables used are correct. > So the solution is to either move these later in the file or use a variable > that is defined further down. > > I tested this by changing TCLLIB_SO to TCLLIB_SO_BLAH in both of these lines, > then added: > > TCLLIB_SO_BLAH = $(TCLLIB_SO) > > as the last line of the makefile. Worked great. > > I don't know why I'm observing this and no one else is. I even built & tested > make-3.79.1 from the tarball, with the same result. Probably you would need a patched version (from cvs if there is one for make or perhaps from RedHat?) > > So anyway I'll make the change so I can install once again. Thanks for installing that workaround to the make problem. Alan |
From: Alan W. I. <ir...@be...> - 2002-08-05 15:22:08
|
On Mon, 5 Aug 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Wild guess to explain all this: on RH7.3 the linux system is somehow not > > being recognized properly so lib_sh_linux.in is not being included as part > > of the Makefile? > > It's included. For some reason the first definition is being used and not the > second. and a further oddment is the first definition is being used with SO undefined. > I just commented out the first definition and reran 'make install' > and after that the install works fine. Very odd. > > ged$ make -v > GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. I have the same make version 3.79.1, but from the Debian changelog there are 14 (!) patches to it (many upstream from GNU) since it came out in September. Some of those have to do with variables so I suspect the RH version isn't quite up to snuff. Have you done your RH package updates? Also, are we pushing gnu-make too much with this variable overriding business? I have just looked fairly carefully in the info documentation under the variable section, and I cannot find any reference to what happens if you define a variable twice. (I know what would happen in Fortran....;-)) Alan |
From: Maurice L. <mj...@ga...> - 2002-08-05 21:00:46
|
Alan W. Irwin writes: > Also, are we pushing gnu-make too much with this variable overriding > business? I have just looked fairly carefully in the info documentation > under the variable section, and I cannot find any reference to what happens > if you define a variable twice. (I know what would happen in > Fortran....;-)) I do recall struggling with the issue back when I built the current system of base definitions coupled with overrides, but I don't remember the details. Fortunately in this case the dependency info wasn't actually being used so could just be chopped. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |