[Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

[Alan W. I. <ir...@be...>]

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
__________________________