From: Alan W. I. <ir...@be...> - 2002-07-29 00:37:30
|
Joao: please read all of this before you comment....;-) tkwin.c is now split into tkwin_common.c and tkwin.c following pretty much what I did in the xwin_common.c and xwin.c case. In direct analogy with the xwin_common case there was a plplot_tkwin_ccmap definition that I had to deal with. I probably did it in a clumsy way so if anybody can come up with a better solution, please commit it (and same remark about plplot_ccmap in the xwin_common case). There may also be some compiler warning issues, but I leave that to the C experts here to fix up. A separate tkwin_common.c is necessary because both plplotter.c and (the new) tkwin.c depend on the functions defined in there. Vince, I think the only practical difference this will make to you is you have to deal with tkwin_common.c now. Now on to the Linux library reorganization: (1) It works! (which is quite important to me). I have not done my complete tests, but I did try the tk device from various front ends, and also pltcl, plserver, and wish (all from plplot/tmp with LD_LIBRARY set to ./). The wish recipe is now changed (as noted also in examples/tk/README.tkdemos.) wish source pldefaults.tcl load libplplottcltkd.so Plplotter package provide Plplotter 5.1.0 source runAllDemos.tcl libplplotd will no longer work in that second line because of the reorganized linking (see below), but this way is more logical in any case. Vince, years ago when we first played with this I recall there was a way to run tkdemos.tcl under wish and tcldemos.tcl under tclsh. I cannot do that at the moment, but are we close to that status again? (2) Joao: your last message seemed rather irritated by my changes, but please think of this as one step in a process rather than the final perfect solution. I have carefully read your e-mails on this subject, and I believe others here have as well (and I also hope Geoffrey makes a special effort to do so when he gets back). If I read you correctly, you want to split libraries up some more beyond what I have done already. I am not against that at all. In fact, I would love to see tclAPI.c get more and more lonely in its library to make it as parallel as possible with the nice clean interface we have for python. So I am basically on your side. But I was concerned your arguments did not take library linking constraints into account which are absolutely dictated by the source file contents. However, if you can find a way to do what you want without introducing reverse linking (see below), I would have no objection at all. (3) IMPORTANT Shared library linking constraints: Here is the deal as I understand it. Suppose in Linux you have liba depending on libx and libx depending on liby. What I mean by "depending on" here is that liba requires some functions that are defined in libx and libx requires some functions that are defined in liby. Special note: these dependencies are completely dictated by the content of the C code, i.e., the actual objects that get put into each library. Also, it is important to have the dependencies one way only to avoid cross-dependency issues (and of course that was the motivation for splitting xwin and tkwin.) In Linux you can be completely sloppy about the way you link liba, libx, and liby together and also the way you link your applications. For example, you can link liba to liby and liby to libx and your applications to liba and it or any other permutation will work on Linux! But it won't work cross-platform because some platforms demand only forward linking, e.g., reverse-linking (against the dependency) liby to libx won't work on some platforms. For cross-platform use the safe way to do things for the above dependency heirarchy is to link to the highest members in the hierarchy that a given application or library is dependent on. That is, link your applications only to liba, liba only to libx, and libx only to liby. That will continue to work fine on Linux. But for cross-platform use one more step is required; you must use libtool to translate automatically for each platform this hiearchy of dependencies you have specified into something that works fine for each platform. libtool handles all the details of taking account of the linker limitations of every platform. But my understanding from reading the libtool documentation is if you build in reverse linking or cross linking, you are hosed! The current status is the linking changes I made today are consistent with the hierarchical rule above and the known linking dependencies that we have as dictated by the current contents of the libraries. libplplottcktk depends on and links to libplplot and libtclmatrix; all dynamic drivers other than xwin, tkwin, and tk depend on and link to libplplot; the xwin, tkwin, and tk drivers depend both on libplplottcktk and libplplot, but only link to libplplottcktk (the higher member in the hierarchy); and libplplot and libtclmatrix depend on no other libraries in plplot so link to none of them. No library depends on a dynamic driver. Most applications (e.g., x01c, plrender) depend only on libplplot so that is all they link to. pltcl and plserver depend both on libplplottcktk and libplplot, but only need to link to the higher member, libplplottcktk. Joao, if you decide to split or reorganize the libraries (including dynamic drivers) some more, please be really careful of the dependencies (dictated by exactly which functions you put into the various libraries and dynamic drivers) so that your changes do not introduce cross-linking, reverse linking, or linking of libraries to dynamic drivers again. Such a mess would probably work on Linux, but would destroy the potential we have at the moment for nice cross-platform handling of our linking with libtool. 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 __________________________ |
From: <jc...@fe...> - 2002-07-29 03:25:43
|
On Monday 29 July 2002 01:37, Alan W. Irwin wrote: | Joao: please read all of this before you comment....;-) =2E.. | | (2) Joao: your last message seemed rather irritated by my changes, Perhaps. I apologize. I'm needing vacations, which will arrive in a=20 couple of days, after the end of semester paper-work is finished. I will see all you within a month. Till then, keep doing a good work=20 Alan (but wait for a consensum, or at least for a resignation :-) Joao |
From: Alan W. I. <ir...@be...> - 2002-07-29 15:16:02
|
I also apologize if I moved too fast. But I also am time constrained, so i= t was a question of do it now or forget it. Also, I thought in this case tha= t the best way was to demonstrate in CVS a working solution to the problem of making the tk, xwin, and tkwin drivers dynamic. This solution does not preclude more changes so long as we avoid reverse-linking and the like. Glad for that smiley below.... Alan email: ir...@be... phone: 250-727-2902=09FAX: 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 Mon, 29 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Monday 29 July 2002 01:37, Alan W. Irwin wrote: > | Joao: please read all of this before you comment....;-) > ... > | > | (2) Joao: your last message seemed rather irritated by my changes, > > Perhaps. I apologize. I'm needing vacations, which will arrive in a > couple of days, after the end of semester paper-work is finished. > > I will see all you within a month. Till then, keep doing a good work > Alan (but wait for a consensum, or at least for a resignation :-) > > Joao > > > > > ------------------------------------------------------- > 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-07-29 16:32:40
|
>> A separate tkwin_common.c is necessary because both plplotter.c and (the new) tkwin.c depend on the functions defined in there. >> I have to say, I find this crazy! It is not possible to use plplotter.c without tkwin.c and not possible to use tkwin.c without plplotter.c so, please, put them in the same .so! -- Vince <http://www.santafe.edu/~vince> On Sun, 28 Jul 2002, Alan W. Irwin wrote: > Joao: please read all of this before you comment....;-) > > tkwin.c is now split into tkwin_common.c and tkwin.c following pretty > much what I did in the xwin_common.c and xwin.c case. > > In direct analogy with the xwin_common case there was a plplot_tkwin_ccmap > definition that I had to deal with. I probably did it in a clumsy way so > if anybody can come up with a better solution, please commit it (and > same remark about plplot_ccmap in the xwin_common case). There may also > be some compiler warning issues, but I leave that to the C experts here > to fix up. > > A separate tkwin_common.c is necessary because both plplotter.c and (the new) > tkwin.c depend on the functions defined in there. > > Vince, I think the only practical difference this will make to you is you > have to deal with tkwin_common.c now. > > Now on to the Linux library reorganization: > > (1) It works! (which is quite important to me). I have not done my complete > tests, but I did try the tk device from various front ends, and also pltcl, > plserver, and wish (all from plplot/tmp with LD_LIBRARY set to ./). > > The wish recipe is now changed (as noted also in examples/tk/README.tkdemos.) > > wish > source pldefaults.tcl > load libplplottcltkd.so Plplotter > package provide Plplotter 5.1.0 > source runAllDemos.tcl > > libplplotd will no longer work in that second line because of the > reorganized linking (see below), but this way is more logical in any case. > > Vince, years ago when we first played with this I recall there was a > way to run tkdemos.tcl under wish and tcldemos.tcl under tclsh. I cannot > do that at the moment, but are we close to that status again? > > (2) Joao: your last message seemed rather irritated by my changes, but > please think of this as one step in a process rather than the final perfect > solution. I have carefully read your e-mails on this subject, and I believe > others here have as well (and I also hope Geoffrey makes a special effort to > do so when he gets back). If I read you correctly, you want to split > libraries up some more beyond what I have done already. I am not against > that at all. In fact, I would love to see tclAPI.c get more and more lonely > in its library to make it as parallel as possible with the nice clean > interface we have for python. So I am basically on your side. But I was > concerned your arguments did not take library linking constraints into > account which are absolutely dictated by the source file contents. However, > if you can find a way to do what you want without introducing reverse > linking (see below), I would have no objection at all. > > (3) IMPORTANT Shared library linking constraints: > > Here is the deal as I understand it. Suppose in Linux you have liba > depending on libx and libx depending on liby. What I mean by "depending on" > here is that liba requires some functions that are defined in libx and libx > requires some functions that are defined in liby. Special note: these > dependencies are completely dictated by the content of the C code, i.e., the > actual objects that get put into each library. Also, it is important to > have the dependencies one way only to avoid cross-dependency issues (and of > course that was the motivation for splitting xwin and tkwin.) > > In Linux you can be completely sloppy about the way you link liba, libx, and > liby together and also the way you link your applications. For example, you > can link liba to liby and liby to libx and your applications to liba and it > or any other permutation will work on Linux! But it won't work > cross-platform because some platforms demand only forward linking, e.g., > reverse-linking (against the dependency) liby to libx won't work on some > platforms. > > For cross-platform use the safe way to do things for the above dependency > heirarchy is to link to the highest members in the hierarchy that a given > application or library is dependent on. That is, link your applications > only to liba, liba only to libx, and libx only to liby. That will continue > to work fine on Linux. But for cross-platform use one more step is > required; you must use libtool to translate automatically for each platform > this hiearchy of dependencies you have specified into something that works > fine for each platform. libtool handles all the details of taking account > of the linker limitations of every platform. But my understanding from > reading the libtool documentation is if you build in reverse linking or > cross linking, you are hosed! > > The current status is the linking changes I made today are consistent with > the hierarchical rule above and the known linking dependencies that we have > as dictated by the current contents of the libraries. libplplottcktk > depends on and links to libplplot and libtclmatrix; all dynamic drivers > other than xwin, tkwin, and tk depend on and link to libplplot; the xwin, > tkwin, and tk drivers depend both on libplplottcktk and libplplot, but only > link to libplplottcktk (the higher member in the hierarchy); and libplplot > and libtclmatrix depend on no other libraries in plplot so link to none of > them. No library depends on a dynamic driver. Most applications (e.g., x01c, > plrender) depend only on libplplot so that is all they link to. pltcl and > plserver depend both on libplplottcktk and libplplot, but only need to link > to the higher member, libplplottcktk. > > Joao, if you decide to split or reorganize the libraries (including dynamic > drivers) some more, please be really careful of the dependencies (dictated > by exactly which functions you put into the various libraries and dynamic > drivers) so that your changes do not introduce cross-linking, reverse > linking, or linking of libraries to dynamic drivers again. Such a mess > would probably work on Linux, but would destroy the potential we have at the > moment for nice cross-platform handling of our linking with libtool. > > 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 > __________________________ > > > > ------------------------------------------------------- > 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-07-29 18:36:46
|
On Mon, 29 Jul 2002, Vince Darley wrote: > >> > A separate tkwin_common.c is necessary because both plplotter.c and (the > new) > tkwin.c depend on the functions defined in there. > >> > > I have to say, I find this crazy! It is not possible to use plplotter.c > without tkwin.c and not possible to use tkwin.c without plplotter.c so, > please, put them in the same .so! OK. A quick visual check of the source codes seemed to indicate moving Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems to depend on anything in those functions. IMPORTANT *all* these functions have to be moved since Plplotter_Init.o depends on plplotter, and if you leave it behind you create a cross-dependency and this affects the wish recipe, see below. Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its usual message without any linking troubles at all. Same for plserver. runAllDemos.tcl worked fine. But now the wish recipe we had before doesn't work... wish % source pldefaults.tcl % load libplplottcltkd.so Plplotter couldn't find procedure Plplotter_Init Obviously it is looking for Plplotter_Init inside libplplottcltkd.so and cannot find it since that has been moved to tkwind_drv.so. So now the new wish recipe from plplot/tmp should be source pldefaults.tcl load drivers/tkwind_drv.so Plplotter package provide Plplotter 5.1.0 source runAllDemos.tcl which works fine and makes sense under the hierarchical linking rules that are now in place since tkwin depends on and links to libplplottcltk. However, attempting to find tkwind_drv at its install location of $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble. For example, you will probably have to specify the complete path name to get it. Ultimately, this could be solved with a symlink. Vince, if this is the way you want to go (reuniting tkwin_common with tkwin and moving Plplotter_Init.o and plplotter.o from libplplottcltk to drivers/tkwind_drv.so while accepting the wish recipe changes that result) that is fine with me, but I need direct confirmation from you before I go to the additional configuration work to make this the permanent solution. Alan |
From: Vince D. <vi...@sa...> - 2002-07-30 08:57:48
|
I think this is the right way to go --- makes sense both logically, and 'symbol-link-ably', at least to me. thanks for investigating and carrying out all this tricky work. -- Vince <http://www.santafe.edu/~vince> On Mon, 29 Jul 2002, Alan W. Irwin wrote: > On Mon, 29 Jul 2002, Vince Darley wrote: > > > >> > > A separate tkwin_common.c is necessary because both plplotter.c and (the > > new) > > tkwin.c depend on the functions defined in there. > > >> > > > > I have to say, I find this crazy! It is not possible to use plplotter.c > > without tkwin.c and not possible to use tkwin.c without plplotter.c so, > > please, put them in the same .so! > > OK. A quick visual check of the source codes seemed to indicate moving > Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to > drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems > to depend on anything in those functions. > > IMPORTANT *all* these functions have to be moved since Plplotter_Init.o > depends on plplotter, and if you leave it behind you create a > cross-dependency and this affects the wish recipe, see below. > > Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its > usual message without any linking troubles at all. > > Same for plserver. runAllDemos.tcl worked fine. > > But now the wish recipe we had before doesn't work... > > wish > % source pldefaults.tcl > % load libplplottcltkd.so Plplotter > couldn't find procedure Plplotter_Init > > Obviously it is looking for Plplotter_Init inside > libplplottcltkd.so and cannot find it since that has been moved > to tkwind_drv.so. > > So now the new wish recipe from plplot/tmp should be > > source pldefaults.tcl > load drivers/tkwind_drv.so Plplotter > package provide Plplotter 5.1.0 > source runAllDemos.tcl > > which works fine and makes sense under the hierarchical linking rules that > are now in place since tkwin depends on and links to libplplottcltk. > However, attempting to find tkwind_drv at its install location of > $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble. For > example, you will probably have to specify the complete path name to get it. > Ultimately, this could be solved with a symlink. > > Vince, if this is the way you want to go (reuniting tkwin_common with tkwin > and moving Plplotter_Init.o and plplotter.o from libplplottcltk to > drivers/tkwind_drv.so while accepting the wish recipe changes that result) > that is fine with me, but I need direct confirmation from you before I go to > the additional configuration work to make this the permanent solution. > > Alan > > |
From: Alan W. I. <ir...@be...> - 2002-07-30 17:28:42
|
I have implemented this change in CVS by simply moving TKWIN_OBJ = Plplotter_Init$O plplotter$O tkwin_common$O from libplplottcltkd to drivers/tkwind_drv.so. Maurice, could I have your comments on doing something similar for the xwin driver? In particular is it possible to move plframe$O from libplplottcltk to xwind_drv.so without introducing a libplplottcltk dependency on xwind_drv.so and thus introducing a cross-dependency between the two since xwind_drv.so will always depend on libplplottcltk? I resolved that potential cross-dependency issue in the present case by also moving Plplotter_Init$O to tkwind_drv.so because there was nothing else in libplplottcltk that depended on Plplotter_Init$O. However, I think in the plframe$O case, there may be other objects within libplplottcltk that depend upon it and which themselves cannot be moved to xwind_drv.so without creating other cross-dependencies. If you cannot see any way to move plframe$O and related objects to xwind_drv.so without creating cross-dependencies, then I suggest you go ahead with the alternative solution you have proposed of using escape functions. The rest of this e-mail concerns some additional tkwin issues and is mostly directed to Vince. I have left tkwin_common.c separate for the moment because I am of two minds about reuniting it with tkwin.c. On the one hand, it is one extra file that Vince has to keep track of. On the other hand, my instinct is to keep this file separate since conceptually it is different from the rest of xwin (i.e.,both xwin.c and plplotter.c depend on the functions defined inside it), and I prefer not to destroy the work I did to separate it. Admittedly, that separation is not necessary at this time, but it might make future changes easier to keep things split. I will leave this decision to your best judgement, Vince, since you are the one most familiar with this area of PLplot. The other immediate remaining issue is what symlinks should be set up to $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so in the installed case. I believe that question is related to Tcl/Tk packaging issues and what directories are searched by the load command for installed dll's. So Vince, will you do the next steps in CVS to package everything for the installed case? Just tell me what directory and name (probably libtkwin$(LIB_TAG).so) you need for the shared object that is loaded, and I will symlink it on the Linux/Unix side to the appropriate tkwind_drv.so install location. Just to remind you what tcl stuff in installed, here is the contents of $prefix/lib/plplot5.1.0/tcl currently installed on my system. ls /usr/local/plplot/lib/plplot5.1.0/tcl/ FileSelector.tcl cmap0a.pal cmap1d.pal plcolor.tcl* pltools.tcl PLWin.itk cmap1a.pal help_gui.tcl plconfig.tcl plwidget.tcl PLXWin.itk cmap1a1.pal help_keys.tcl pldefaults.tcl tclIndex Pltkwin.tcl cmap1b.pal help_tcltk.tcl plplot.tcl about.tcl cmap1c.pal plclient.tcl plserver.tcl Also, you haven't yet answered my question about running tcldemos.tcl from tclsh and tkdemos.tcl from wish. I know we used to be able to do that on the tea branch years ago, and I would like to see that neat functionality available on cvs HEAD as well. 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 Tue, 30 Jul 2002, Vince Darley wrote: > I think this is the right way to go --- makes sense both logically, and > 'symbol-link-ably', at least to me. > > thanks for investigating and carrying out all this tricky work. > > -- Vince > > <http://www.santafe.edu/~vince> > > > On Mon, 29 Jul 2002, Alan W. Irwin wrote: > > > On Mon, 29 Jul 2002, Vince Darley wrote: > > > > > >> > > > A separate tkwin_common.c is necessary because both plplotter.c and (the > > > new) > > > tkwin.c depend on the functions defined in there. > > > >> > > > > > > I have to say, I find this crazy! It is not possible to use plplotter.c > > > without tkwin.c and not possible to use tkwin.c without plplotter.c so, > > > please, put them in the same .so! > > > > OK. A quick visual check of the source codes seemed to indicate moving > > Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to > > drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems > > to depend on anything in those functions. > > > > IMPORTANT *all* these functions have to be moved since Plplotter_Init.o > > depends on plplotter, and if you leave it behind you create a > > cross-dependency and this affects the wish recipe, see below. > > > > Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its > > usual message without any linking troubles at all. > > > > Same for plserver. runAllDemos.tcl worked fine. > > > > But now the wish recipe we had before doesn't work... > > > > wish > > % source pldefaults.tcl > > % load libplplottcltkd.so Plplotter > > couldn't find procedure Plplotter_Init > > > > Obviously it is looking for Plplotter_Init inside > > libplplottcltkd.so and cannot find it since that has been moved > > to tkwind_drv.so. > > > > So now the new wish recipe from plplot/tmp should be > > > > source pldefaults.tcl > > load drivers/tkwind_drv.so Plplotter > > package provide Plplotter 5.1.0 > > source runAllDemos.tcl > > > > which works fine and makes sense under the hierarchical linking rules that > > are now in place since tkwin depends on and links to libplplottcltk. > > However, attempting to find tkwind_drv at its install location of > > $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble. For > > example, you will probably have to specify the complete path name to get it. > > Ultimately, this could be solved with a symlink. > > > > Vince, if this is the way you want to go (reuniting tkwin_common with tkwin > > and moving Plplotter_Init.o and plplotter.o from libplplottcltk to > > drivers/tkwind_drv.so while accepting the wish recipe changes that result) > > that is fine with me, but I need direct confirmation from you before I go to > > the additional configuration work to make this the permanent solution. > > > > Alan > > > > > > |
From: Vince D. <vi...@sa...> - 2002-08-02 14:31:03
|
>>> The other immediate remaining issue is what symlinks should be set up to $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so in the installed case. I believe that question is related to Tcl/Tk packaging issues and what directories are searched by the load command for installed dll's. >>> Retaining the tkwin_common.c split seems fine. 'load' will search anything on your path, but, by and large all normal uses of 'load' specify a full path, so it's not so much of an issue. for easiest use with tcl/tk, we will need to install something into the tcl/tk hierarchy so it is automatically picked up by them. We need to put a directory (called, say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that directory, together with appropriate information on where to find the .so it will be loading (currently that pkgIndex.tcl assumes that everything it is looking for will also be in that directory, since that is how things are installed for a normal Tcl extension). -- Vince <http://www.santafe.edu/~vince> |
From: Alan W. I. <ir...@be...> - 2002-08-02 18:06:14
|
Let's get down to specifics. Currently, all the tcl stuff is installed here ls /usr/local/plplot/lib/plplot5.1.0/tcl FileSelector.tcl cmap0a.pal cmap1d.pal plcolor.tcl* pltools.tcl PLWin.itk cmap1a.pal help_gui.tcl plconfig.tcl plwidget.tcl PLXWin.itk cmap1a1.pal help_keys.tcl pldefaults.tcl tclIndex Pltkwin.tcl cmap1b.pal help_tcltk.tcl plplot.tcl about.tcl cmap1c.pal plclient.tcl plserver.tcl and the drivers are installed here ls /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so where /usr/local/plplot is my prefix. Are you suggesting copying bindings/tk-x-plat/pkgIndex.tcl to $prefix/lib/plplot5.1.0/tcl and also putting a symbolic link from that directory to the actual driver share object location (so it appears the shared object is in the same directory as pkgIndex.tcl)? I think you also imply below that autopath would have to be changed to find /usr/local/plplot/lib/plplot5.1.0/tcl, but I may be misunderstanding you. What would be the exact wish recipe associated with what you would like me to do? Please give me the full wish cookbook. Currently, my linking changes of moving everything to tkwind_drv.so seems to have confused the ability of wish to find the *.tcl files in /usr/local/plplot/lib/plplot5.1.0/tcl, and I am hoping that problem will get straightened out by the changes you suggest (perhaps the autopath change?) that are associated with the using the pkgIndex.tcl file. Incidentally, the library linking changes cause no problems with /usr/local/plplot/bin/plserver source tkdemos.tcl 1 2 3 ... but now if I try source runAllDemos.tcl instead, it (unlike tkdemos.tcl) cannot find the x??.tcl examples in the current directory. I have no idea why subtleties of linking are having this bad effect on the runAllDemos.tcl case, but I hope you are able to change runAllDemos.tcl to look in the current directory for x??.tcl so it won't be so sensitive to linking changes. 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 Fri, 2 Aug 2002, Vince Darley wrote: > [...] 'load' will search > anything on your path, but, by and large all normal uses of 'load' specify > a full path, so it's not so much of an issue. for easiest use with > tcl/tk, we will need to install something into the tcl/tk hierarchy so it > is automatically picked up by them. We need to put a directory (called, > say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's > auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that > directory, together with appropriate information on where to find the .so > it will be loading (currently that pkgIndex.tcl assumes that everything it > is looking for will also be in that directory, since that is how things > are installed for a normal Tcl extension). > > -- Vince > > <http://www.santafe.edu/~vince> > > > > |
From: Vince D. <vi...@sa...> - 2002-08-05 10:20:24
|
What we would like, under Wish, is for the following to work: > wish % package require Plplotter 5.1.0 % plframe .p etc etc. Now, for 'package require Plplotter' to work, there must be an appropriate pkgIndex.tcl file somewhere that tcl is going to search by default. Clearly tcl is never going to search in any /usr/local/plplot by default, so that means we must install something *extra* into a location that tcl will search. Tcl uses the 'auto_path' as the set of directories to look for subdirectories which contain new pkgIndex.tcl files. For example, on Windows, my auto_path is this: % set auto_path {C:/Program Files/Tcl/lib/tcl8.4} {C:/Program Files/Tcl/lib} {C:/Program Files/Tcl/lib/tcllib0.8} {C:/Program Files/Tcl/lib/tk8.4} The second one of these (.../tcl/lib) is the most generic. If I create a directory in there (..../tcl/lib/plplot5.1.0/) and put a pkgIndex.tcl file inside that directory, then tcl will find it automatically. This is what we want. Having done that, we then have a choice whether to put all the rest of the tcl bindings in that directory as well (symlinks if desired), or whether that pkgindex actually just points Tcl to /usr/local/plplot/.... instead. That is a choice for all of you to make. If you wish to allow the tcl/tk plplot bindings to be used when they are wrapped inside a standalone tcl/tk executable (which would be nice) then there should at least be the option of putting everything in the Tcl hierarchy. I would suggest making symlinks to everything that might be needed in that directory (including the .fnt, .map files). hope that helps, -- Vince <http://www.santafe.edu/~vince> On Fri, 2 Aug 2002, Alan W. Irwin wrote: > Let's get down to specifics. Currently, all the tcl stuff is installed here > > ls /usr/local/plplot/lib/plplot5.1.0/tcl > FileSelector.tcl cmap0a.pal cmap1d.pal plcolor.tcl* pltools.tcl > PLWin.itk cmap1a.pal help_gui.tcl plconfig.tcl plwidget.tcl > PLXWin.itk cmap1a1.pal help_keys.tcl pldefaults.tcl tclIndex > Pltkwin.tcl cmap1b.pal help_tcltk.tcl plplot.tcl > about.tcl cmap1c.pal plclient.tcl plserver.tcl > > and the drivers are installed here > > ls /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so > /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so > > where /usr/local/plplot is my prefix. > > Are you suggesting copying bindings/tk-x-plat/pkgIndex.tcl to > $prefix/lib/plplot5.1.0/tcl and also putting a symbolic link from > that directory to the actual driver share object location (so it appears > the shared object is in the same directory as pkgIndex.tcl)? I think you > also imply below that autopath would have to be changed to find > /usr/local/plplot/lib/plplot5.1.0/tcl, but I may be misunderstanding you. > > What would be the exact wish recipe associated with what you would like me > to do? > > Please give me the full wish cookbook. Currently, my linking changes of > moving everything to tkwind_drv.so seems to have confused the ability of > wish to find the *.tcl files in /usr/local/plplot/lib/plplot5.1.0/tcl, and I > am hoping that problem will get straightened out by the changes you suggest > (perhaps the autopath change?) that are associated with the using the > pkgIndex.tcl file. > > Incidentally, the library linking changes cause no problems with > > /usr/local/plplot/bin/plserver > source tkdemos.tcl > 1 > 2 > 3 > ... > > but now if I try source runAllDemos.tcl instead, it (unlike tkdemos.tcl) > cannot find the x??.tcl examples in the current directory. I have no idea > why subtleties of linking are having this bad effect on the runAllDemos.tcl > case, but I hope you are able to change runAllDemos.tcl to look in the > current directory for x??.tcl so it won't be so sensitive to linking > changes. > > 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 Fri, 2 Aug 2002, Vince Darley wrote: > > > [...] 'load' will search > > anything on your path, but, by and large all normal uses of 'load' specify > > a full path, so it's not so much of an issue. for easiest use with > > tcl/tk, we will need to install something into the tcl/tk hierarchy so it > > is automatically picked up by them. We need to put a directory (called, > > say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's > > auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that > > directory, together with appropriate information on where to find the .so > > it will be loading (currently that pkgIndex.tcl assumes that everything it > > is looking for will also be in that directory, since that is how things > > are installed for a normal Tcl extension). > > > > -- Vince > > > > <http://www.santafe.edu/~vince> > > > > > > > > > > |
From: Alan W. I. <ir...@be...> - 2002-08-05 17:20:02
|
Vince, The reason why we cannot install anything into fixed system locations is many unix users do not have root privileges. However, they are still able to install plplot in their own home directory (or some other disk area they have control of) using the appropriate prefix. Using a prefix this way for tarball packages has become the unix/linux standard so I imagine there are nice ways to make non-standard prefixes work for tcl. The question is how to find those nice ways. From what you say below, it seems to me you could just tell the user (or configure the examples) to set autopath to set autopath $prefix/lib/plplot5.1.0/tcl so it could find the pkgIndex.tcl file there (that file is not currently installed there, but we could do that easily). Would that gain access to pkgIndex.tcl or am I missing something? Assuming you could access a special version of pkgIndex.tcl this way, what *specific* changes would have to be made to that file so everything else would work with the tcl files installed in $prefix/lib/plplot5.1.0/tcl and the libraries installed in $prefix/lib including a symlink (called libtkwin[d].so, say) from there pointing to $prefix/lib/plplot5.1.0/drivers/tkwin[d]_drv.so. I need the specifics because my tcl skills are just at the newbie level. 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 Mon, 5 Aug 2002, Vince Darley wrote: > What we would like, under Wish, is for the following to work: > > > wish > % package require Plplotter > 5.1.0 > % plframe .p > etc etc. > > Now, for 'package require Plplotter' to work, there must be an appropriate > pkgIndex.tcl file somewhere that tcl is going to search by default. > Clearly tcl is never going to search in any /usr/local/plplot by default, > so that means we must install something *extra* into a location that tcl > will search. Tcl uses the 'auto_path' as the set of directories to look > for subdirectories which contain new pkgIndex.tcl files. For example, on > Windows, my auto_path is this: > > % set auto_path > {C:/Program Files/Tcl/lib/tcl8.4} {C:/Program Files/Tcl/lib} {C:/Program > Files/Tcl/lib/tcllib0.8} {C:/Program Files/Tcl/lib/tk8.4} > > The second one of these (.../tcl/lib) is the most generic. If I create a > directory in there (..../tcl/lib/plplot5.1.0/) and put a pkgIndex.tcl file > inside that directory, then tcl will find it automatically. This is what > we want. > > Having done that, we then have a choice whether to put all the rest of the > tcl bindings in that directory as well (symlinks if desired), or whether > that pkgindex actually just points Tcl to /usr/local/plplot/.... instead. > That is a choice for all of you to make. If you wish to allow the tcl/tk > plplot bindings to be used when they are wrapped inside a standalone > tcl/tk executable (which would be nice) then there should at least be the > option of putting everything in the Tcl hierarchy. I would suggest making > symlinks to everything that might be needed in that directory (including > the .fnt, .map files). > > hope that helps, > > -- Vince > > <http://www.santafe.edu/~vince> > > > On Fri, 2 Aug 2002, Alan W. Irwin wrote: > > > Let's get down to specifics. Currently, all the tcl stuff is installed here > > > > ls /usr/local/plplot/lib/plplot5.1.0/tcl > > FileSelector.tcl cmap0a.pal cmap1d.pal plcolor.tcl* pltools.tcl > > PLWin.itk cmap1a.pal help_gui.tcl plconfig.tcl plwidget.tcl > > PLXWin.itk cmap1a1.pal help_keys.tcl pldefaults.tcl tclIndex > > Pltkwin.tcl cmap1b.pal help_tcltk.tcl plplot.tcl > > about.tcl cmap1c.pal plclient.tcl plserver.tcl > > > > and the drivers are installed here > > > > ls /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so > > /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so > > > > where /usr/local/plplot is my prefix. > > > > Are you suggesting copying bindings/tk-x-plat/pkgIndex.tcl to > > $prefix/lib/plplot5.1.0/tcl and also putting a symbolic link from > > that directory to the actual driver share object location (so it appears > > the shared object is in the same directory as pkgIndex.tcl)? I think you > > also imply below that autopath would have to be changed to find > > /usr/local/plplot/lib/plplot5.1.0/tcl, but I may be misunderstanding you. > > > > What would be the exact wish recipe associated with what you would like me > > to do? > > > > Please give me the full wish cookbook. Currently, my linking changes of > > moving everything to tkwind_drv.so seems to have confused the ability of > > wish to find the *.tcl files in /usr/local/plplot/lib/plplot5.1.0/tcl, and I > > am hoping that problem will get straightened out by the changes you suggest > > (perhaps the autopath change?) that are associated with the using the > > pkgIndex.tcl file. > > > > Incidentally, the library linking changes cause no problems with > > > > /usr/local/plplot/bin/plserver > > source tkdemos.tcl > > 1 > > 2 > > 3 > > ... > > > > but now if I try source runAllDemos.tcl instead, it (unlike tkdemos.tcl) > > cannot find the x??.tcl examples in the current directory. I have no idea > > why subtleties of linking are having this bad effect on the runAllDemos.tcl > > case, but I hope you are able to change runAllDemos.tcl to look in the > > current directory for x??.tcl so it won't be so sensitive to linking > > changes. > > > > 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 Fri, 2 Aug 2002, Vince Darley wrote: > > > > > [...] 'load' will search > > > anything on your path, but, by and large all normal uses of 'load' specify > > > a full path, so it's not so much of an issue. for easiest use with > > > tcl/tk, we will need to install something into the tcl/tk hierarchy so it > > > is automatically picked up by them. We need to put a directory (called, > > > say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's > > > auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that > > > directory, together with appropriate information on where to find the .so > > > it will be loading (currently that pkgIndex.tcl assumes that everything it > > > is looking for will also be in that directory, since that is how things > > > are installed for a normal Tcl extension). > > > > > > -- Vince > > > > > > <http://www.santafe.edu/~vince> > > > > > > > > > > > > > > > > > > |
From: Vince D. <vi...@sa...> - 2002-08-05 17:33:45
|
On Mon, 5 Aug 2002, Alan W. Irwin wrote: > >From what you say below, it seems to me you could just tell the user > (or configure the examples) to set autopath > to > > set autopath $prefix/lib/plplot5.1.0/tcl Yes, not the most helpful to the user but it would work. Perhaps we can add to the plplot documentation that users can add the above to their .wishrc file. I've checked in a version of pkgIndex.tcl which, if installed in the above location, will try to load ../drivers/libtkwin[d].so -- please give it a test. cheers, Vince. |
From: Alan W. I. <ir...@be...> - 2002-08-05 19:12:55
|
First, thanks for the plplotter.c changes. It now compiles without the fatal error (but with the warnings as you suggested would occur for tcl8.3). I did the usual wish test in the plplot/tmp area, and it worked fine. Second, I then installed everything. Also I created a symbolic link so that ls -l /usr/local/plplot/lib/libtkwind.so lrwxrwxrwx 1 software software 55 Aug 5 11:27 /usr/local/plplot/lib/libtkwind.so -> /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so I then changed your latest pkgIndex.tcl so the two relevant lines read grep libtkwin /usr/local/plplot/lib/plplot5.1.0/tcl/pkgIndex.tcl set file [file join $dir ../.. libtkwind[info sharedlibextension]] set file [file join $dir ../.. libtkwind[info sharedlibextension]] (Note the "d" suffix has nothing to do with debugging so more changes are required in this file. Instead it marks the libraries and drivers as double-precision versions (which is the case for me. Nevertheless, let's not worry about it for now. I can just hack this to do what I want locally for now, and we can figure out the configuration issues later.) For example, I added an extra "../" and dropped drivers from the list of joined symbols because I wanted to point to the symlink above in /usr/local/plplot/lib. However, no matter how I fiddle with these two lines, I always get the following error message: wish % set autopath /usr/local/plplot/lib/plplot5.1.0/tcl /usr/local/plplot/lib/plplot5.1.0/tcl % package require Plplotter can't find package Plplotter As far as I can see the above set file command should work (and many other variants I tried), but I think it is never being executed. As an experiment I put in a puts $file command in /usr/local/plplot/lib/plplot5.1.0/tcl/pkgIndex.tcl, but package require PLplotter never output that value of the file variable. Perhaps autopath does not work like you thought? If I attempt to puts $autopath from wish before I define it above it tells me it is undefined. 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 Mon, 5 Aug 2002, Vince Darley wrote: > On Mon, 5 Aug 2002, Alan W. Irwin wrote: > > >From what you say below, it seems to me you could just tell the user > > (or configure the examples) to set autopath > > to > > > > set autopath $prefix/lib/plplot5.1.0/tcl > > Yes, not the most helpful to the user but it would work. Perhaps we can > add to the plplot documentation that users can add the above to their > .wishrc file. > > I've checked in a version of pkgIndex.tcl which, if installed in the above > location, will try to load ../drivers/libtkwin[d].so -- please give it a > test. > > cheers, > > Vince. > > > |