PLplot

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: irwin@...
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    mjl@...
> 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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)

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    mjl@...
> 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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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>

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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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

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

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

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>

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    mjl@...
Research Organization for Information Science and Technology of Japan (RIST)