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 > |