Menu
▾
▴
Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(
|
From: Vince D. <vi...@sa...> - 2002-07-12 08:17:09
|
Try putting plplotter.c in the tiny dll with tkwin.c... -- Vince <http://www.santafe.edu/~vince> On Thu, 11 Jul 2002, Alan W. Irwin wrote: > As an experiment I tried the following local changes to turn tkwin into > a dynamic driver (i.e., a tiny dll that is loaded as needed by the core > plplot routines): > > cvs diff > Index: configure.in > =================================================================== > RCS file: /cvsroot/plplot/plplot/cf/configure.in,v > retrieving revision 1.134 > diff -u -3 -p -r1.134 configure.in > --- configure.in 11 Jul 2002 20:05:52 -0000 1.134 > +++ configure.in 12 Jul 2002 00:47:18 -0000 > @@ -133,12 +133,12 @@ hp7470, hp7580, lj_hpgl, ljiip, imp, xwi > # Note specifically which drivers are known to be loadable. Eventually, > # hopefully, every driver will show up on this list. However, we add them one > # at a time since each will have its own peculiarities in the build process > -# (only ones missing at present: xwin and tk and tkwin). > +# (only ones missing at present: xwin and tk). > > define([PL_DYNAMIC_DRIVER_LIST], > [plmeta null xterm tek4010 tek4010f tek4107 tek4107f mskermit \ > conex linuxvga vlt versaterm dg300 png jpeg cgm ps psc xfig ljii \ > -hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk]) > +hp7470 hp7580 lj_hpgl ljiip imp pbm gnome pstex ntk tkwin]) > > # We think of a "device" as the output medium. Could be a machine > # style (Tektronix, X11), or a file format (Postscript). > Index: dyndrv.in > =================================================================== > RCS file: /cvsroot/plplot/plplot/cf/dyndrv.in,v > retrieving revision 1.24 > diff -u -3 -p -r1.24 dyndrv.in > --- dyndrv.in 9 Jul 2002 19:52:58 -0000 1.24 > +++ dyndrv.in 12 Jul 2002 00:47:18 -0000 > @@ -61,8 +61,8 @@ drivers/impress$(LIB_TAG).drv : shared/i > drivers/gnome$(LIB_TAG).drv : shared/gnome$O $(PLLIBS) > $(SHLIB_BUILD) $@ $< @GNOMELIBS@ $(driverlibs) > > -#drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS) > -# $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs) > +drivers/tkwin$(LIB_TAG).drv : shared/tkwin$O $(PLLIBS) > + $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs) > > drivers/ntk$(LIB_TAG).drv : shared/ntk$O $(PLLIBS) > $(SHLIB_BUILD) $@ $< @TKLIBS@ $(driverlibs) > > However, these changes do not work (so I won't commit them). > > The problem is that the link step for applications shows undefined symbols: > > make > gcc -g plrender.o -L. -lplplotd -ltclmatrixd -o plrender \ > -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm > -lg2c -Wl,-rpath -Wl,/home/software/plplot_cvs/HEAD/plplot_working3/tmp > ./libplplotd.so: undefined reference to PLColor_from_TkColor_Changed' > ./libplplotd.so: undefined reference to plplot_tkwin_ccmap' > ./libplplotd.so: undefined reference to plD_dispatch_init_tkwin' > ./libplplotd.so: undefined reference to plD_open_tkwin' > ./libplplotd.so: undefined reference to pltkwin_setBGFG' > collect2: ld returned 1 exit status > make: *** [plrender] Error 1 > > These symbols are referred to by plplotter.c, and putting plplotter.o into > libplplot is causing the problem. > > My understanding is that similar problems (Tcl/Tk stuff integrated into > libplplot) keep the tk driver (and therefore xwin) from being dynamic. > > I think it is crazy to have Tcl/Tk stuff (or code from any other front end) > inside libplplot so I hope we can rationalize this situation. Of course, > once the Tcl/Tk front end code is in its own separate library, then the next > step is to turn that into a dll which could be dynamically loaded into wish > or tclsh (using the TEA-based approach, I presume). Separating out the > python front-end stuff into dll's is exactly the python approach we have > used both with the old and present python interfaces. That idea works very > well so I am anxious to see it tried for the Tcl/Tk case, and a side benefit > I understand is it allows us to convert our remaining static drivers (tk, > xwin, and tkxwin) optionally into dynamic drivers as well. > > I believe we have concluded previously that a separate Tcl/Tk library and > ultimately dll was the way to go. I don't have the expertise to do this > myself, but if somebody is inspired to take responsibility for this change, > I will certainly cheer from the sidelines, and also I will be more than > happy to help with the configuration and testing of the result! > > 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 > PC Mods, Computing goodies, cases & more > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
