Re: [Plplot-devel] build broken

[<jc...@fe...>]

On Saturday 31 August 2002 13:24, Alan W. Irwin wrote:
| 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!=20
| All the tcl and tk interface stuff is now split off from libplplot
| into its own library libplplottcltk[d].

This is a good thing.
Can we make also a libplplotf77 library from scstubs.o sfstubs.o?

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

That's fine.

|  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

Good. Of course this implies that the user has to specify the location=20
of tkwin_drv.so.
It's easy to do in the build directory, but might cause problems in the=20
installed location--the user must know where it is. From other e-mails=20
I understand that the problem was already solved setting 'auto_path' by=20
using 'lappend', I just dont know if this is performed automatically or=20
if it requires the user to set it up.

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

That's fine. The only missing thing is to reunify tkwin_common.c and=20
tkwin.c, I believe.

Unfortunately it is not possible to do with the tk driver the same thing=20
that was done with the tkwin one -- put everything that is driver=20
dependent in tk_drv.so. This is because plframe.o, tcpip.o and plr.o=20
are also needed by tkwin.

The other object files in libplplottcltk.* (but tclAPI.o) are=20
application dependent, and should, I think, be linked directly with the=20
applications they were written for, as they are useless for other=20
programs or the user:  Pltk_Init.o is for the tk_win driver (and I=20
checked that if removed from libplplottcltk.so and included in=20
drivers/tkwin_drv.so the tkwin driver still works), tclMain.o is for=20
pltcl, and tkMain.o is for plserver.
With these changes, libplplottcltk.* would contain only tclAPI.o,=20
plframe.o, tcpip.o and plr.o.

These changes would only clarify what is from what, without any=20
advantages or disadvantages.

What do you think of this last proposal?

Joao

| 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
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by: OSDN - Tired of that same old
| cell phone?  Get a new here for FREE!
| https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel