From: Geoffrey F. <fu...@ga...> - 2002-08-31 05:30:17
|
I did a fresh checkout tonight, first time in a while. configured with nothing special...: command: ../configure --prefix=/home/furnish/xenon --disable-f77 --disable-cxx --with-double system: Linux-2.4.18-3smp prefix: /home/furnish/xenon CC: gcc -c -O LDC: gcc INCS: -I. -I/home/furnish/xenon/include LIBS: -L/home/furnish/xenon/lib -litk3.2 -ltk8.3 -litcl3.2 -ltcl8.3 -L/usr/X11R6/lib -lX11 -lgd -lpng -ljpeg -lz -ldl -lm LIB_TAG: d devices: plmeta null xterm tek4010 tek4010f tek4107 tek4107f mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470 hp7580 lj_hpgl ljiip imp xwin tk pbm pstex Available device drivers static: plmeta null tek dg300 gd ps xfig ljii hpgl ljiip impress tk pbm pstex xwin dynamic: with_shlib: yes with_double: yes with_debug: no with_opt: yes with_warn: no with_profile: no with_gcc: yes with_rpath: yes enable_xwin: yes enable_tcl: yes enable_tk: yes enable_itcl: yes enable_cxx: no enable_python: no enable_f77: no enable_java: no enable_octave: no enable_gnome: no enable_tkwin: no ran make, and got: [furnish@dhcp-814-13 tmp]$ make gcc -c -O -I. -I/home/furnish/xenon/include -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o [...] cd shared; \ gcc -shared -fPIC -o ../libplplottcltkd.so.5.1.0 \ -Wl,-soname -Wl,libplplottcltkd.so.5 \ tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o xwin.o tclMain.o tkMain.o -L.. -lplplotd -ltclmatrixd \ -L/home/furnish/xenon/lib -ltcl8.3 -litcl3.2 -ltk8.3 -litk3.2 -L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp ln -sf libplplottcltkd.so.5.1.0 libplplottcltkd.so.5 ln -sf libplplottcltkd.so.5 libplplottcltkd.so gcc -c -O -I. -I/home/furnish/xenon/include -MD -MF .d.plrender -MP -c plrender.c -o plrender.o gcc plrender.o -L. -lplplotd -o plrender \ -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp ./libplplotd.so: undefined reference to `Tcl_DeleteInterp' ./libplplotd.so: undefined reference to `gdImageColorAllocate' ./libplplotd.so: undefined reference to `gdImageColorDeallocate' ./libplplotd.so: undefined reference to `Tcl_Init' ./libplplotd.so: undefined reference to `Tcl_GetOpenFile' ./libplplotd.so: undefined reference to `Tcl_DoOneEvent' ./libplplotd.so: undefined reference to `pls_auto_path' ./libplplotd.so: undefined reference to `plWait_Until' ./libplplotd.so: undefined reference to `gdImageDestroy' ./libplplotd.so: undefined reference to `pl_PacketSend' ./libplplotd.so: undefined reference to `plD_dispatch_init_xw' ./libplplotd.so: undefined reference to `Tcl_CreateInterp' ./libplplotd.so: undefined reference to `gdImagePalettePixel' ./libplplotd.so: undefined reference to `gdImageLine' ./libplplotd.so: undefined reference to `gdImagePng' ./libplplotd.so: undefined reference to `gdImageJpeg' ./libplplotd.so: undefined reference to `Tcl_SetVar' ./libplplotd.so: undefined reference to `Tcl_GetVar' ./libplplotd.so: undefined reference to `Tk_Init' ./libplplotd.so: undefined reference to `Tcl_AppendResult' ./libplplotd.so: undefined reference to `gdImageCreate' ./libplplotd.so: undefined reference to `Tcl_ExprBoolean' ./libplplotd.so: undefined reference to `Tcl_CreateCommand' ./libplplotd.so: undefined reference to `gdImageFilledPolygon' ./libplplotd.so: undefined reference to `Tcl_SetVar2' ./libplplotd.so: undefined reference to `Tcl_VarEval' collect2: ld returned 1 exit status make: *** [plrender] Error 1 So, it looks like, for some reason, linking plrender is droping the -ltcl -ltk -lgd, and all that. 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? -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2002-08-31 12:24:28
|
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 |
From: <jc...@fe...> - 2002-09-16 16:28:49
|
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 |
From: Alan W. I. <ir...@be...> - 2002-09-16 18:21:13
|
On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Saturday 31 August 2002 13:24, Alan W. Irwin wrote: > | [...]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]. > > This is a good thing. > Can we make also a libplplotf77 library from scstubs.o sfstubs.o? I hope so. If I recall correctly, this has long been on Maurice's ToDo lis= t. Geoffrey, would you also be willing to go along with splitting out the java interface stuff from libplplot if I do the work? Ultimately, I would like to see all interface API removed from libplplot. I think it just makes maintenance issues a lot easier to solve if we move toward reserving libplplot exclusively for fundamental PLplot API. Ultimately, I guess it just boils down to the Unix philosophy of splitting everything up into small specialized entities which communicate well (in this case by the link= ing mechanism) rather than attempting an integrated approach. > | [...] 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 > of tkwin_drv.so. > It's easy to do in the build directory, but might cause problems in the > installed location--the user must know where it is. From other e-mails > I understand that the problem was already solved setting 'auto_path' by > using 'lappend', I just dont know if this is performed automatically or > if it requires the user to set it up. I got everything to work well in the build location, but there are still some Tcl/Tk install issues which I have now forgotten but which I documente= d to the list. I suspect there is a simple solution, but it will need to be provided by a Tcl Linux expert. > > That's fine. The only missing thing is to reunify tkwin_common.c and > tkwin.c, I believe. I don't care one way or the other here, and I believe the same is true for Vince. So if you want to reunite tkwin, please go ahead. > > [...] The other object files in libplplottcltk.* (but tclAPI.o) are > application dependent, and should, I think, be linked directly with the > applications they were written for, as they are useless for other > programs or the user: Pltk_Init.o is for the tk_win driver (and I > checked that if removed from libplplottcltk.so and included in > drivers/tkwin_drv.so the tkwin driver still works), tclMain.o is for > pltcl, and tkMain.o is for plserver. > With these changes, libplplottcltk.* would contain only tclAPI.o, > plframe.o, tcpip.o and plr.o. > > These changes would only clarify what is from what, without any > advantages or disadvantages. Sounds good to me! Unfortunately, it is taking me longer than I thought to finish my current astronomical research project (partly because I have been sneaking in a lot of work on short plplot projects) so it may be late October *at the earliest* before I can get to this. So if you could do it first, I would much appreciate it. Alan |
From: Maurice L. <mj...@ga...> - 2002-09-16 21:34:15
|
Jo=E3o Cardoso writes: > This is a good thing. > Can we make also a libplplotf77 library from scstubs.o sfstubs.o? One of these days, definitely. > That's fine. The only missing thing is to reunify tkwin_common.c and= =20 > tkwin.c, I believe. I was going to do this, along the same lines as the reunified xwin.c an= d xwin_common.c. Unfortunately it appears to be a bit more work than the= former, so since the current situation is reasonable, I decided to leav= e it as-is for now. --=20 Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (= RIST) |