Thread: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

Sorry for my extended silence.  Very busy here.

Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
driver isn't working for me in this configuration.

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> Hi all,
>
> Sorry for my extended silence.  Very busy here.

Always glad to hear from you.

>
> Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
> driver isn't working for me in this configuration.

Last I checked it worked fine for Tcl/Tk 8.3.3.  Sorry, I don't have time
right now to try a later version of Tcl/Tk.

Does PLplot cvs HEAD work okay for you with Tcl/Tk 8.3?  A positive or
negative result there would narrow down where the problem is.

Alan

The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
working" doesn't shed too much light on your problem ;-)

-- Vince

<http://www.santafe.edu/~vince>

On Wed, 6 Nov 2002, Alan W. Irwin wrote:

> On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
>
> > Hi all,
> >
> > Sorry for my extended silence.  Very busy here.
>
> Always glad to hear from you.
>
> >
> > Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
> > driver isn't working for me in this configuration.
>
> Last I checked it worked fine for Tcl/Tk 8.3.3.  Sorry, I don't have time
> right now to try a later version of Tcl/Tk.
>
> Does PLplot cvs HEAD work okay for you with Tcl/Tk 8.3?  A positive or
> negative result there would narrow down where the problem is.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Vince Darley writes:
 > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
 > working" doesn't shed too much light on your problem ;-)

I cannot configure plplot cvs head against a prefix with installations
of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
build complete successfully.  Looking at the link lines that fail, it
is clear that libraries are being dropped, which contain needed
symbols.  Vince, you're not building on Linux are you?

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> Vince Darley writes:
>  > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
>  > working" doesn't shed too much light on your problem ;-)
>
> I cannot configure plplot cvs head against a prefix with installations
> of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
> build complete successfully.  Looking at the link lines that fail, it
> is clear that libraries are being dropped, which contain needed
> symbols.

Library dropping is unlikely to be the cause of your problem.  As far as I
know the present linking scheme works fine for everybody else using tcl/tk
on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
cannot confirm your problem, we need to get together off list to make more
exact comparisons, and in fact I have just initiated that process.

Alan

Alan W. Irwin writes:
 > On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
 > 
 > > Vince Darley writes:
 > >  > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
 > >  > working" doesn't shed too much light on your problem ;-)
 > >
 > > I cannot configure plplot cvs head against a prefix with installations
 > > of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
 > > build complete successfully.  Looking at the link lines that fail, it
 > > is clear that libraries are being dropped, which contain needed
 > > symbols.
 > 
 > Library dropping is unlikely to be the cause of your problem.  As far as I
 > know the present linking scheme works fine for everybody else using tcl/tk
 > on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
 > cannot confirm your problem, we need to get together off list to make more
 > exact comparisons, and in fact I have just initiated that process.

I think it may be due to not including --enable-dyndrivers, which is required
at present.  Hmm.. mayhaps a change to the configure default is warranted?
I mean, if the default doesn't build.. that doesn't make sense.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
 >  > > I cannot configure plplot cvs head against a prefix with installations
 >  > > of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
 >  > > build complete successfully.  Looking at the link lines that fail, it
 >  > > is clear that libraries are being dropped, which contain needed
 >  > > symbols.
 >  > 
 >  > Library dropping is unlikely to be the cause of your problem.  As far as I
 >  > know the present linking scheme works fine for everybody else using tcl/tk
 >  > on Linux (Maurice, Joao, and me) so long as we use dynamic drivers.  Since I
 >  > cannot confirm your problem, we need to get together off list to make more
 >  > exact comparisons, and in fact I have just initiated that process.
 > 
 > I think it may be due to not including --enable-dyndrivers, which is required
 > at present.  Hmm.. mayhaps a change to the configure default is warranted?
 > I mean, if the default doesn't build.. that doesn't make sense.

Well, the network demons conspired against me tonight, so I won't be
able to read my work email till tomorrow, where I suppose some of
Alan's response went.  Following up only on this part:

Yes, I did do a static drivers config, and no it won't build, and no
I'm not imagining things, but no I also didn't know that it was known
that it didn't work, although now that you say it, it does ring a
distant bell.

I am ambivalent to which is the default, but I do feel strongly that
sstatic builds should work.

However, I also should say here, that I did a dyndrivers config first,
and that didn't build for me either, also failing during a link.  But
in subsequent consideration, I realized that might have been at least
partially attributable to not having had LD_LIBRARY_PATH set right.  I
had one bug report on the non functioning dyndrivers config composed,
but I deleted it without sending it, after I reran the build with
LD_L_P set.  

I'll try to make a detailed post tomorrow on what I'm having trouble
with.  My problems today were discovered only shortly before I had to
leave work, so I didn't have time for a totally detailed analysis.

I spent some time tonight reviewing the email traffic during my
hibernation.  I'm really amazed at how much cool stuff has been going
on.  Great job everybody.

On the subject of linking and all that, I found some emails from a
couple months back, indicating that it was all still under
discussion.  And the last thing I was working on, was a "struct of
function pointers" abstraction to decouple drivers from libplplot
proper.  I had made some real headway on that, but got distracted
before a commit.  I'll try to resurrect this stuff over the next few
days and get it in.  I really believe this will have a substantial
positive effect on decoupling things in a way that is robust, and
comprehensible. 

More later, cheers,

-- 
Geoffrey Furnish         fu...@ga...

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> I am ambivalent to which is the default, but I do feel strongly that
> sstatic builds should work.

Agreed.  But all in good time for the release.  However, because the current
cvs head works (at least for particular combinations of configuration
options under linux) static drivers are somewhat down the list of my
priorities at the moment.

Here is my "library" issue list prioritized from high to low.

(1) AT (autotools).  This is going to take some time for me to learn plus
some time for me to implement.  But once Linux with shared libraries and
dynamic drivers works with AT to everybody's satisfaction, then the changes
to make static drivers work, static libraries work, and to support other
Unix platforms should be quite straightforward compared to the current
configuration system.

(2) I think some more work simplifying libplplottcltk may be in order. If I
recall correctly, Joao mentioned some modules that were simply used for one
executable so he advocated keeping those *.o files outside of any library
and simply linking them on the command line.  I don't know whether that is a
bad or good idea, but it needs more discussion.  I am looking for a
volunteer to implement it if the consensus is this is a good idea.  This
can be done with the present shared library, dyn driver system or it can
wait until after AT.

(3) Separate out the language interface stuff (e.g., java, fortran) that
currently is is mixed in with the plotting API in libplplot.  Again I need a
volunteer, and this can be done before or after AT.

For production use before the next release, 5.1.0 is quite capable, and CVS
HEAD does work under Linux (I hope to prove that tomorrow for
Geoffrey....;-)).  Thus, I have felt fairly relaxed about not being able to
contribute much in the last two months to make some progress on the above
library issues.  And I realize the rest of you are under time constraints as
well.  But the goal before the next release is library linking that works
much better than any previous release.  I think we are already pretty much
there on Linux for the specific case of shared libraries and dynamic
devices.  But to add all the bells and whistles like static devices or
libraries and to make it work cross platform is going to take quite an
additional effort.  We will get there sooner or later depending on how many
volunteers help, and at that point we will release.

Alan

Geoffrey Furnish writes:
 > I'll try to make a detailed post tomorrow on what I'm having trouble
 > with.

Okay.  Here's the deal.  cvs head static driver builds are busted.
Everybody seems to have known that but I had forgotten.

Using --enable-dyndrivers, I can get a build, but only if I have
LD_LIBRARY_PATH set to .:$prefix.  I don't think we should leave it
like that.  Specification of correct -rpaths can alleviate that, and
we should eventuall fix the build system to supply them in all the
right places.  I ordinarily in my professional development activities,
do not ever need to set LD_L_P.

But, the Tk driver only works if I build against an old Tcl/Tk.  cvs
head's Tk driver does not work when built against Tcl/Tk 8.4.1.  If
you type x01c, tk, it just hangs.  If you try to run plserver
directly, it exits immediately with error code 1.

[furnish@xiphi tmp]$ ldd plserver
        libplplottcltk.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libplplottcltk.so.5
(0x40014000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        libtcl.so.0 => /usr/lib/libtcl.so.0 (0x4004f000)
        libtk.so.0 => /usr/lib/libtk.so.0 (0x400cf000)
        libplplot.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libplplot.so.5 (0x4017b000)
        libtclmatrix.so.5 =>
/home/furnish/devel/tcl/841/plplot/tmp/libtclmatrix.so.5 (0x401ae000)
        libitcl3.2.so =>
/home/furnish/fastflow/tcl-841/lib/libitcl3.2.so (0x401b3000)
        libitk3.2.so =>
/home/furnish/fastflow/tcl-841/lib/libitk3.2.so (0x401cd000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401d7000)
        libdl.so.2 => /lib/libdl.so.2 (0x402ac000)
        libm.so.6 => /lib/i686/libm.so.6 (0x402af000)
        libgcc_s.so.1 => /opt/gcc-3.2/lib/libgcc_s.so.1 (0x402d1000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[furnish@xiphi tmp]$ ./plserver
[furnish@xiphi tmp]$ echo $?
1
[furnish@xiphi tmp]$ 

With cvs head built against Tcl/Tk 8.3.3, ./plserver pops up a top
level and gives you a prompt.

So, something is wrong with that.  

BTW, the build is almost clean when we build against Tcl/Tk 8.3.3, but
there are oodles of warnings in the build against Tcl/Tk 8.4.1.
Evidently they changed some const qualifiers on some of the publi Tcl
API functions.  I don't know if we can solve these interface binding
issues in plplot with casts.  I do know that in one of my C++
projects, it is illegal to make the casts needed, so the Tcl client
code actually has to be changed to support the new const qualifiers on
the Tcl API functions.  Sheesh, this is awfully late in the game for
the Tcl guys to discover const.  Maybe C will be more permissive.
grrr. 

-- 
Geoffrey Furnish         fu...@ga...

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> Geoffrey Furnish writes:
>  > I'll try to make a detailed post tomorrow on what I'm having trouble
>  > with.
>
> Okay.  Here's the deal.  cvs head static driver builds are busted.
> Everybody seems to have known that but I had forgotten.
>
> Using --enable-dyndrivers, I can get a build, but only if I have
> LD_LIBRARY_PATH set to .:$prefix.  I don't think we should leave it
> like that.  Specification of correct -rpaths can alleviate that, and
> we should eventuall fix the build system to supply them in all the
> right places.  I ordinarily in my professional development activities,
> do not ever need to set LD_L_P.

Some time ago I complained bitterly that the java interface to PLplot
requires setting LD_LIBRARY_PATH.  Despite much reading of java manuals we
couldn't find any way to wiggle out of it.  Since I always routinely include
java in my PLplot builds, I also routinely set LD_LIBRARY_PATH. Like
you, I would prefer not to set LD_LIBRARY_PATH at all, but I would be a lot
more sensitive to the issue for non-java parts of PLplot, if we could find a
solution for the java part.

**I need some clarification from you**.  Do you get good results for tcl-8.3
with LD_LIBRARY_PATH set? If so, then that settles my principal concern that
we were getting different results.

It sounds from your other preliminary results that there will be some
substantial effort required to get PLplot to work with later versions of
tcl/tk on Linux.  I am glad you are working on that.  Although, tcl-8.3 is
the version used in my current distribution (Debian stable), I notice
tcl-8.4 is already in Debian testing, and I assume it is the version of
choice (or soon will be the version of choice) for other distributions as
well.

Alan

Geoffrey Furnish writes:
 > But, the Tk driver only works if I build against an old Tcl/Tk.  cvs
 > head's Tk driver does not work when built against Tcl/Tk 8.4.1.  If
 > you type x01c, tk, it just hangs.  If you try to run plserver
 > directly, it exits immediately with error code 1.
 > [...]
 > With cvs head built against Tcl/Tk 8.3.3, ./plserver pops up a top
 > level and gives you a prompt.
 > 
 > So, something is wrong with that.  

Grrrr.  I was able, with lots of recompiling the universe, to get as
far as stepping through plserver, to find that the source of the
trouble is that the call to Itcl_Init in tkMain.c, fails, which causes
plserver to exit straight away.

I cannot see why this fails.  But for whatever reason, Itcl 3.2.1,
appears to be incompatible with Tcl 8.4.1.  I tried to debug inside
the Itcl_Init call, but alas, the itcl 3.2.1 configure script emits a
bogus makefile if you configure --enable-symbols, and so you can't
build a debuggable itcl 3.2.1.  I guess one could hack the makefile
after configuring, but I'm getting winded after all this skulldugery. 

Vince, you reported success with Tcl/Tk 8.4.1.  Was that with
Itcl/Itk, or not?  If so, what itcl are you using?  There has been no
Itcl release since the release of Tcl/Tk 8.4.1.

I should add, if you build Itcl/Itk 3.2.1 against Tcl/Tk 8.4.1, you
/can/ get an itk wish, just by going into tclsh and saying package
require Itk.  So that works fine.  But the tkMain.c call to Itcl_Init,
fails, but it worked with itcl 3.2.1 built against Tcl/Tk 8.3.x.

-- 
Geoffrey Furnish         fu...@ga...

>>
Vince, you reported success with Tcl/Tk 8.4.1.  Was that with
Itcl/Itk, or not?  If so, what itcl are you using?  There has been no
Itcl release since the release of Tcl/Tk 8.4.1.
>>

I've only used itcl/itk via "package require" (and indeed, only use Plplot
via that route as well), so I'm not sure what the Itcl issue is. (Also on
Windows only at present).

sorry not to be more helpful,

-- Vince

<http://www.santafe.edu/~vince>

Geoffrey Furnish writes:
 > Grrrr.  I was able, with lots of recompiling the universe, to get as
 > far as stepping through plserver, to find that the source of the
 > trouble is that the call to Itcl_Init in tkMain.c, fails, which causes
 > plserver to exit straight away.
 > 
 > I cannot see why this fails.  But for whatever reason, Itcl 3.2.1,
 > appears to be incompatible with Tcl 8.4.1.  

Well, I don't understand what could've caused this change, but the
bottom line is that you have to set ITCL_LIBRARY to
$prefix/lib/itcl3.2, and similarly for ITK_LIBRARY, in order for
plserver to run. Setting these environment variables is not necessary
when using itcl3.2.1 over tcl/tk 8.3.x.  Bizarre.  With that, plserver
works fine.

But I face more impediments to using plplot cvs head in my day job.
plplot-config --libs no longer reports something that works.  

I know people are real hip on splitting all the language bindings out
of libplplot proper, but those language bindings are there because
applications use them.  So if we're going to go this route, then
plplot-config needs to keep pace, and I guess, grow options so it can
spit out all the binding-specific drivel that has to be done just
right. 

-- 
Geoffrey Furnish         fu...@ga...

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> I know people are real hip on splitting all the language bindings out
> of libplplot proper, but those language bindings are there because
> applications use them.  So if we're going to go this route, then
> plplot-config needs to keep pace, and I guess, grow options so it can
> spit out all the binding-specific drivel that has to be done just
> right.

I have already answered you privately, but I made mistakes in my response so
please forget it.

First, I just checked and plplot-config has been kept up to date with the
linking simplification that occurred in July, and I don't think much has
changed since.

Secondly, I cannot confirm your problem with plplot-config.  For example,
plrender and all the x??c examples are linking well for me now using it.
This happens automatically if you build the installed examples, see
Makedemo.

Would you please confirm that you can build the installed examples on your
system with the latest PLplot cvs and tcl-8.3?

If that is the case, then the obvious next question is what are you doing
differently for your own toolchain so that plplot-config does not work for
that specific case? One possibility is your toolchain may *directly* refer
to tcl/tk symbols.  If that is the case then you have to link those
libraries in, independently of plplot-config.  I am sorry if that is the
case. However, remember the function of plplot-config is to link in the
libplplot library.  It does that job well, and that is all most applications
(e.g., plrender, x??c) need.  Recall that with the current linking scheme,
linking to the tcl/tk libraries is necessary only for the drivers that
explicitly reference tcl/tk symbols (e.g., tkd_drv.so) and for the
libplplottcltk library.  The present scheme does that linking automatically
when you you build those drivers or the libplplottcltk library.  Even pltcl
and plserver don't refer to tcl/tk symbols directly so their linking only
involves the libplplottcltk library.

Another possibility is your toolchain refers to symbols in libplplottcltk.
Currently, we don't have an option for that case in plplot-config because it
is not needed in the install, but we should develop such an option as a
convenience for our users. Volunteers?

Alan

Alan W. Irwin writes:
 > On Thu, 7 Nov 2002, Geoffrey Furnish wrote:
 > 
 > > I know people are real hip on splitting all the language bindings out
 > > of libplplot proper, but those language bindings are there because
 > > applications use them.  So if we're going to go this route, then
 > > plplot-config needs to keep pace, and I guess, grow options so it can
 > > spit out all the binding-specific drivel that has to be done just
 > > right.
 > 
 > I have already answered you privately, but I made mistakes in my response so
 > please forget it.
 > 
 > First, I just checked and plplot-config has been kept up to date with the
 > linking simplification that occurred in July, and I don't think much has
 > changed since.
 > 
 > Secondly, I cannot confirm your problem with plplot-config.  

Hmm.  I've blown away that config by now, so I can't check without
redoing it all, but I'm thinking now that it is possible that I may
have used the wrong plplot-config.  I thought I was doing it right at
the time, but maybe I biffed this part of it.  So, don't sweat that
unless I write back to confirm.

 > Would you please confirm that you can build the installed examples on your
 > system with the latest PLplot cvs and tcl-8.3?

Not today, but I'll do this exercise again and let you know.

 > If that is the case, then the obvious next question is what are you doing
 > differently for your own toolchain so that plplot-config does not work for
 > that specific case? One possibility is your toolchain may *directly* refer
 > to tcl/tk symbols.  If that is the case then you have to link those
 > libraries in, independently of plplot-config.  I am sorry if that is the
 > case. However, remember the function of plplot-config is to link in the
 > libplplot library.  

Right.  My app does do that, but I wasn't blaming plplot-config for
not (any longer) including -ltk and all that.  I completely agree,
plplot-config --libs is only there to tell you how to link PLplot, so
the behavior you describe is correct.

 > It does that job well, and that is all most applications
 > (e.g., plrender, x??c) need.  Recall that with the current linking scheme,
 > linking to the tcl/tk libraries is necessary only for the drivers that
 > explicitly reference tcl/tk symbols (e.g., tkd_drv.so) and for the
 > libplplottcltk library.  The present scheme does that linking automatically
 > when you you build those drivers or the libplplottcltk library.  Even pltcl
 > and plserver don't refer to tcl/tk symbols directly so their linking only
 > involves the libplplottcltk library.
 > 
 > Another possibility is your toolchain refers to symbols in libplplottcltk.

Yes, that's me.  By building a PLplot-enhanced Tcl shell, I am
effectively a glorified pltcl or plserver.  So my app calls
Pltcl_init, Pltk_init, etc.

 > Currently, we don't have an option for that case in plplot-config because it
 > is not needed in the install, but we should develop such an option as a
 > convenience for our users. Volunteers?

Anyone building a PLplot-enhanced Tcl shell, will need this.  I think
this is what triggered my first email on this point, although I'll
still try to run the experiment again at some point, and confirm.

I think my app does not specifically have to do the Pltcl/Pltk tie-in
during AppInit.  I don't have other init-time compiled code that needs
plframe.  So, if we had it so that "package require Pltk" was
serviceable, then maybe I wouldn't have to mimick pltcl's startup
code.

I haven't looked at this for a while.  My recollection was that pltcl
was pretty sophisticated, and it paid to mimick it carefully.  I'm not
sure we can really recover exactly what we need, using only a package
based approach.  I hope so, but I would regard that as somewhat
innovative, starting from where I think we are.  But maybe my memory
on this paints the beast larger than life.  I'll have to go back and
look at this, at some point.

Anyway, my point is this.  For sure, apps need to be able to get
plframe registered in their own custom Tcl_Interp *.  The way I have
always done this, is to call Pltcl_init/Pltk_init, which requires
plplot-config --libs to tell all that is required for that to work.
That requirement could maybe be dropped, if there was a Tcl-level way
to get plframe installed in the interpreter.  That's the TEA branch
stuff.  I know its worked for Vince in that context, but I don't think
we have this full capability on cvs head yet, do we?

-- 
Geoffrey Furnish         fu...@ga...

On Thu, 7 Nov 2002, Geoffrey Furnish wrote:

> I think my app does not specifically have to do the Pltcl/Pltk tie-in
> during AppInit.  I don't have other init-time compiled code that needs
> plframe.  So, if we had it so that "package require Pltk" was
> serviceable, then maybe I wouldn't have to mimick pltcl's startup
> code.
>
> I haven't looked at this for a while.  My recollection was that pltcl
> was pretty sophisticated, and it paid to mimick it carefully.  I'm not
> sure we can really recover exactly what we need, using only a package
> based approach.  I hope so, but I would regard that as somewhat
> innovative, starting from where I think we are.  But maybe my memory
> on this paints the beast larger than life.  I'll have to go back and
> look at this, at some point.
>
> Anyway, my point is this.  For sure, apps need to be able to get
> plframe registered in their own custom Tcl_Interp *.  The way I have
> always done this, is to call Pltcl_init/Pltk_init, which requires
> plplot-config --libs to tell all that is required for that to work.
> That requirement could maybe be dropped, if there was a Tcl-level way
> to get plframe installed in the interpreter.  That's the TEA branch
> stuff.  I know its worked for Vince in that context, but I don't think
> we have this full capability on cvs head yet, do we?

I believe we already have the capability that you need. For example, right
now plframe is directly available from wish just like in the tea branch long
ago.  The recipe for setting that up is in
plplot/examples/tk/README.tkdemos.

But regardless of that issue plplot-config definitely needs options for any
user that develops apps that include reference to library symbols for some
of our additional libraries such as libplplottcltk. I have just put a note
to that effect in PROBLEMS so we will deal with this before the release.

Alan

Thread: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

Cross-platform, scientific graphics plotting library

plplot-devel