Re: [Plplot-devel] build broken

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

On Sat, 31 Aug 2002, Geoffrey Furnish wrote:

> I'm too far behind in my email to know who's been working on such
> things of late.  Does anyone recognize their fingerprint on this
> woopsie?

Mine....;-)

Static drivers don't work at the moment, but I am waiting to fix that until
you (and also Joao) have had a chance to evaluate my new linking scheme for
dynamic drivers which is working well at the moment.  Once we have reached
consensus there, then the changes to make static drivers work should be
straightforward.

The history for the new linking scheme started when I was able to analyze
why we were having troubles with making the xwin, tk, and tkwin (Vince's new
tk driver) into dynamic drivers. Essentially, the problem was caused because
our libraries depended on (directly called functions in) xwin.c and tkwin.c,
while, of course, those dynamic drivers in turn depended on our libraries.
My solution for this Gordian knot was the same as Alexander's.  I split
everything up!  All the tcl and tk interface stuff is now split off from
libplplot into its own library libplplottcltk[d].  Also, my first solution
was all the common functions in xwin.c and tkwin.c (i.e., all those routines
called both by routines in libplplottcltk as well as the the drivers
themselves) were split off from those drivers and put into libplplottcltk.
This solution for the first time gave us working dynamic drivers for xwin,
tk, and tkwin.

However, Joao had objections to using libplplottcltk as simply a grab bag
for these common functions and wanted to reserve libplplottcltk strictly for
interface functions. On the whole, I agree with this goal, but I also did
not want to return to the bad old days where libraries depended explicitly
on functions in driver code making dynamic linking of certain drivers
impossible. Maurice, was kind enough to find a technical solution to this
dilemma; he reunited xwin.c and used an escape function approach for the
parts of xwin.c that were called by routines in libplplottcltk[d].  Thus,
those routines simply call the plplot core and never directly reference
xwin.c which neatly solves the linking issue.  A different solution
(suggested by Vince) for simplifying libplplottcltk was taken for the tkwin
case where everything associated with tkwin was put into the tkwin dynamic
library.  Thus, tkwind_drv.so now contains

Plplotter_Init.o plplotter.o tkwin_common.o tkwin.o


So the current status is that no library depends explicitly on functions in
drivers.  This allows all our drivers to be dynamic which satisfies my
concerns. Furthermore, libplplottcltk has now been
simplified down so that it contains only

tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o  tclMain.o  tkMain.o

I believe this simplification will satisfy most of Joao's concerns, but we
haven't heard his comments yet on the present scheme, and there may be more
that can be done.

Once we reach consensus on what objects go in which libraries, then the next
straightforward step is to get the static drivers to work under Linux.

After that (October at the earliest due to my time constraints), I would
like to make everything work cross-platform, and I have already anticipated
some of the issues there by making the current linking scheme completely
hierarchical under Linux.  That is when we have a chain of library
dependencies so that libw depends on libx depends on liby depends on libz,
the linking step for libw only links in libx, the linking step for libx only
links in liby and the linking step for liby only links in libz. Another way
of saying this is only explicit dependencies are taken into account when
linking and not further dependencies in the chain of libraries. This
hierarchical linking scheme works well under Linux, and it should make it
easier to go cross-platform according to the libtool documentation.

Alan