From: Alan W. I. <ir...@be...> - 2002-07-19 23:40:16
|
I have just committed my changes to split out the pltcl library and I also greatly simplified the linking flags. The old model for linking flags was to "throw in everything but the kitchen sink until the sucker worked". The new model is to attempt to link just what is required and nothing more. With the new model, applications only link libplplot (which is quite convenient); libplplot only links libpltcl, the normal list of dynamic drivers, and libg2c (the library required in Linux for fortran); and finally libpltcl links the tcl, itcl, tk, itk, xwin, libtclmatrix, and the special dynamic drivers. These changes have been tested (my usual interactive and non-interactive tests) in the plplot/tmp location and also in an arbitrary location with the result installed with prefix = /usr/local/plplot. I used the configure options --with-double --enable-dyndrivers --enable-java --enable-gnome --enable-ntk --enable-tkwin I believe this new linking scheme should work for all modern Linux dynamic loaders. (Just for the record, my dynamic loader /lib/ld-2.2.5.so from Debian woody is part of the libc6-2.2.5 package.) However, if I recall correctly there was some evidence in the past that Joao's older patched SuSe distribution had different linking requirements. So Joao and others, please test the latest CVS on your various Linux distributions starting from a fresh checkout from CVS. Note with the new model @LIBS@ (the combination of a zillion different linking flags) is no longer used, but it is still defined in case we need it to support older dynamic loaders. Maurice, I think if you followed what I did for libpltcl, you could also easily split out the fortran interface from libplplot. And similar remarks to Geoffrey about splitting out the java interface from libplplot. Other notes: I believe the current scheme will work also for --disable-dyndrivers. The idea there is the special drivers get absorbed into libpltcl and the rest get absorbed into libplplot. But I haven't tested this at all. I haven't yet thought much about the static library case. For Linux shouldn't we just drop that altogether? Alternatively, we could make it a non-default configuration item for Linux if there are still some important Linux distributions that do not support shared libraries. I haven't thought at all about our other platforms, but I will address that issue once we are completely satisfied about the linking behaviour on Linux. So please test the current CVS hard on as wide a variety of Linux platforms as possible using --enable-dyndrivers. If you want to try it without that flag, I would also be interested in the results, but no guarantees it would work! 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 __________________________ |
From: Vince D. <vi...@sa...> - 2002-07-20 08:10:37
|
A few thoughts, On Fri, 19 Jul 2002, Alan W. Irwin wrote: > convenient); libplplot only links libpltcl, the normal list of dynamic This seesm the wrong way around. Wouldn't libpltcl link to libplplot? > I haven't yet thought much about the static library case. For Linux > shouldn't we just drop that altogether? Alternatively, we could make it a > non-default configuration item for Linux if there are still some important > Linux distributions that do not support shared libraries. It would be nice to still allow someone to compile one executable which contains everything they need (to pass between machines, etc) rather than needing a dozen different files. this new build structure should, I hope, smooth things for integration of the last parts of what I want to do: enable the 'USE_TCL_STUBS' and 'USE_TK_STUBS' flags. Doing this effectively removes the linkage between libpltcl and tcl/tk, so allowing the same libpltcl to be used with any version of Tcl/Tk since 8.1 without recompilation. This makes distributing a binary much more useful! If you'd like, try turning on those flags and see if the 'load libpltcl Plplotter' still works. (I'm pretty sure plrender, pltcl etc would break with this change as they stand, however, but the 'load' bit might work) good work! Vince. |
From: Alan W. I. <ir...@be...> - 2002-07-20 13:52:34
|
On Sat, 20 Jul 2002, Vince Darley wrote: > A few thoughts, > > On Fri, 19 Jul 2002, Alan W. Irwin wrote: > > convenient); libplplot only links libpltcl, the normal list of dynamic > > This seesm the wrong way around. Wouldn't libpltcl link to libplplot? It works now as I have described. I think what is going on is that the Linux dynamic loader makes available all symbols of the preceding libraries in the chain to the linked libraries. So libpltcl does have symbols it needs from libplplot, but the dynloader makes those accessible even though libplplot is linked to libpltcl in the present scheme rather than vice versa. So the way I have set it up makes for the most compact link line for applications. But you are right it makes no logical sense to humans who are used to the old static linking, and on that basis it may make sense to link the other way, and accept a less compact link line which mentions both libplplot and libpltcl. Anybody else have thoughts on this issue? Alan |
From: Maurice L. <mj...@ga...> - 2002-07-24 03:50:36
|
Alan W. Irwin writes: > I have just committed my changes to split out the pltcl library and I > also greatly simplified the linking flags. The old model for linking flags > was to "throw in everything but the kitchen sink until the sucker worked". > The new model is to attempt to link just what is required and nothing more. > > With the new model, applications only link libplplot (which is quite > convenient); libplplot only links libpltcl, the normal list of dynamic > drivers, and libg2c (the library required in Linux for fortran); and finally > libpltcl links the tcl, itcl, tk, itk, xwin, libtclmatrix, and the special > dynamic drivers. > > These changes have been tested (my usual interactive and non-interactive > tests) in the plplot/tmp location and also in an arbitrary location with the > result installed with prefix = /usr/local/plplot. I used the configure > options --with-double --enable-dyndrivers --enable-java --enable-gnome > --enable-ntk --enable-tkwin > ... > I believe the current scheme will work also for --disable-dyndrivers. The > idea there is the special drivers get absorbed into libpltcl and the rest > get absorbed into libplplot. But I haven't tested this at all. At least one problem so far. If enable_png or enable_jpeg are set, nothing links because the -lgd flag is nowhere to be found. Here's my output: cd shared; \ gcc -shared -fPIC -o ../libplplot.so.5.1.0 \ -Wl,-soname -Wl,libplplot.so.5 \ pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o plimage.o plmeta.o null.o gd.o ps.o tk.o pbm.o pstex.o -L.. -ltclmatrix -lpltcl ln -sf libplplot.so.5.1.0 libplplot.so.5 ln -sf libplplot.so.5 libplplot.so gcc -g plrender.o -L. -lplplot -o plrender \ -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp ./libplplot.so: undefined reference to `gdImageColorAllocate' ./libplplot.so: undefined reference to `gdImageColorDeallocate' ./libplplot.so: undefined reference to `gdImageDestroy' ./libplplot.so: undefined reference to `gdImageLine' ./libplplot.so: undefined reference to `gdImagePng' ./libplplot.so: undefined reference to `gdImageJpeg' ./libplplot.so: undefined reference to `gdImageCreate' ./libplplot.so: undefined reference to `gdImageFilledPolygon' collect2: ld returned 1 exit status make: *** [plrender] Error 1 and ditto for x01c, etc. I suppose it's an easy fix but I don't see it. Since you did the change maybe you'll find it quicker than I.. Will let you know if any other problems arise. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-07-24 14:36:54
|
I don't have the problem here. I am confused by your result since libplplot has no references (I believe, although perhaps I am missing something here?) to libgd when dynamic drivers are enabled. Instead, the gd driver (which itself is linked to libgd et al) is dlopened at run time. Did you forget to configure --enable-dyndrivers? The current CVS won't work without it although I intend to address that issue once any problems with the --enable-dyndrivers case are sorted out. 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 __________________________ On Tue, 23 Jul 2002, Maurice LeBrun wrote: > At least one problem so far. If enable_png or enable_jpeg are set, nothing > links because the -lgd flag is nowhere to be found. Here's my output: > > cd shared; \ > gcc -shared -fPIC -o ../libplplot.so.5.1.0 \ > -Wl,-soname -Wl,libplplot.so.5 \ > pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o plimage.o plmeta.o null.o gd.o ps.o tk.o pbm.o pstex.o -L.. -ltclmatrix -lpltcl > ln -sf libplplot.so.5.1.0 libplplot.so.5 > ln -sf libplplot.so.5 libplplot.so > > gcc -g plrender.o -L. -lplplot -o plrender \ > -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp > ./libplplot.so: undefined reference to `gdImageColorAllocate' > ./libplplot.so: undefined reference to `gdImageColorDeallocate' > ./libplplot.so: undefined reference to `gdImageDestroy' > ./libplplot.so: undefined reference to `gdImageLine' > ./libplplot.so: undefined reference to `gdImagePng' > ./libplplot.so: undefined reference to `gdImageJpeg' > ./libplplot.so: undefined reference to `gdImageCreate' > ./libplplot.so: undefined reference to `gdImageFilledPolygon' > collect2: ld returned 1 exit status > make: *** [plrender] Error 1 > > and ditto for x01c, etc. I suppose it's an easy fix but I don't see it. > Since you did the change maybe you'll find it quicker than I.. > > Will let you know if any other problems arise. > > -- > Maurice LeBrun mj...@ga... > Research Organization for Information Science and Technology of Japan (RIST) > |
From: Maurice L. <mj...@ga...> - 2002-07-24 18:16:07
|
Alan W. Irwin writes: > I don't have the problem here. > > I am confused by your result since libplplot has no references (I believe, > although perhaps I am missing something here?) to libgd when dynamic drivers > are enabled. Instead, the gd driver (which itself is linked to libgd et al) > is dlopened at run time. > > Did you forget to configure --enable-dyndrivers? The current CVS won't work > without it although I intend to address that issue once any problems with > the --enable-dyndrivers case are sorted out. I was commenting on the disable-dyndrivers case. Everything else seems ok so far. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: <jc...@fe...> - 2002-07-24 20:20:39
|
On Saturday 20 July 2002 00:40, Alan W. Irwin wrote: =2E.. | | I believe this new linking scheme should work for all modern Linux | dynamic loaders. This doesn't mean that others unices will be forgeted, does it? | (Just for the record, my dynamic loader | /lib/ld-2.2.5.so from Debian woody is part of the libc6-2.2.5 | package.) However, if I recall correctly there was some evidence in | the past that Joao's older patched SuSe distribution had different | linking requirements. So Joao and others, please test the latest CVS | on your various Linux distributions starting from a fresh checkout | from CVS. As I told before, suse-7.2 don't have tkInt.h and other tkInt.h=20 dependent header files. Copying those from the source tarball to /usr=09/include enables the=20 compilation of the tkwin driver, but not running it in plplot tmp dir: [jcard@feup] ./x01c -dev tkwin Plplot library version: 5.1.0 No tk plframe widget to connect to [jcard@feup] ldd x01c libplplotd.so.5 =3D> /home/jcard/plplot-devel/tmp/libplplotd.so.5= =20 libtclmatrixd.so.5 =3D>=20 /home/jcard/plplot-devel/tmp/libtclmatrixd.so.5 libpltcld.so.5 =3D> /home/jcard/plplot-devel/tmp/libpltcld.so.5=20 libplplot_xwin_driverd.so =3D>=20 /home/jcard/plplot-devel/tmp/libplplot_xwin_driverd.so libplplot_tkwin_driverd.so =3D>=20 /home/jcard/plplot-devel/tmp/libplplot_tkwin_driverd.so libdl.so.2 =3D> /lib/libdl.so.2 (0x403d9000) =2E.. Trying to follow the the tkwin receipt gives: [jcard@feup] wish % load libplplotd.so.5.1.0 Plplotter couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: cannot=20 open shared object file: No such file or directory % load libplplotd.so Plplotter couldn't find procedure Plplotter_Init It seems that some path is missing. Coull you please send an updated receipt? I'm afraid that I have not=20 fully following the tkwin thread. Also,=20 [jcard@feup] ./x01c -dev tk Plplot library version: 5.1.0 gives the following error message in a tk window: Invalid command name "plw::create" while executing "plw::create .x01c tk" ("after" script) This also appeared in some messages in the list, but I can't see how to=20 solve it. Finally, the libplplot_tkwin_driverd.so and libplplot_xwin_driverd.so:=20 what are they for? I think that they are there to help the unix loader to find the=20 xxx_drv.so files, but it does not look a clean approach to the=20 problem... perhaps the drivers that know that they will need another=20 driver should ldopen() them themselfs? E.g., if tkwin knows that it=20 needs the xwin driver, than at plD_init_tkwin() it should dlopen=20 drivers/xwind_drv.so? Joao |
From: Maurice L. <mj...@ga...> - 2002-07-24 22:04:50
|
Jo=E3o Cardoso writes: > On Saturday 20 July 2002 00:40, Alan W. Irwin wrote: > ... > | > | I believe this new linking scheme should work for all modern Linux= > | dynamic loaders. >=20 > This doesn't mean that others unices will be forgeted, does it? >=20 > | (Just for the record, my dynamic loader > | /lib/ld-2.2.5.so from Debian woody is part of the libc6-2.2.5 > | package.) However, if I recall correctly there was some evidence i= n > | the past that Joao's older patched SuSe distribution had different= > | linking requirements. So Joao and others, please test the latest = CVS > | on your various Linux distributions starting from a fresh checkout= > | from CVS. >=20 > As I told before, suse-7.2 don't have tkInt.h and other tkInt.h=20 > dependent header files. It's not in the default Tcl/Tk tarball install either. What exactly is= needed from these files? If it's just function prototypes, then no problem, j= ust compile without all the prototypes in place. You can do configure magi= c to use them *if* found. OTOH, if what you need is a structure definiti= on, then the problem is harder to work around. > Trying to follow the the tkwin receipt gives: >=20 > [jcard@feup] wish > % load libplplotd.so.5.1.0 Plplotter > couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: canno= t=20 > open shared object file: No such file or directory >=20 > % load libplplotd.so Plplotter > couldn't find procedure Plplotter_Init > ... I've been unable to get this stuff to work either. --=20 Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (= RIST) |
From: Alan W. I. <ir...@be...> - 2002-07-24 22:42:44
|
On Wed, 24 Jul 2002, Maurice LeBrun wrote: > Jo=E3o Cardoso writes: > > Trying to follow the the tkwin receipt gives: > > > > [jcard@feup] wish > > % load libplplotd.so.5.1.0 Plplotter > > couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: cannot > > open shared object file: No such file or directory > > > > % load libplplotd.so Plplotter > > couldn't find procedure Plplotter_Init > > ... > > I've been unable to get this stuff to work either. I just checked again in plplot/tmp, and I was getting that error also. Turned out setenv LD_LIBRARY_PATH . fixed the problem. (I normally use this in any case since it is also required for java to work, but by accident I didn't have it set this time, hence the error.) So let me know if this solves the problem with wish. Alan |
From: <jc...@fe...> - 2002-07-25 01:44:31
|
On Wednesday 24 July 2002 23:42, Alan W. Irwin wrote: | On Wed, 24 Jul 2002, Maurice LeBrun wrote: | > Jo=E3o Cardoso writes: | > > Trying to follow the the tkwin receipt gives: | > > | > > [jcard@feup] wish | > > % load libplplotd.so.5.1.0 Plplotter | > > couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: | > > cannot open shared object file: No such file or directory | > > | > > % load libplplotd.so Plplotter | > > couldn't find procedure Plplotter_Init | > > ... | > | > I've been unable to get this stuff to work either. | | I just checked again in plplot/tmp, and I was getting that error | also. Turned out | | setenv LD_LIBRARY_PATH . | | fixed the problem. Yes, it worked for me too. Joao | | (I normally use this in any case since it is also required for java | to work, but by accident I didn't have it set this time, hence the | error.) | | So let me know if this solves the problem with wish. | | Alan | | | | ------------------------------------------------------- | This sf.net email is sponsored by: Jabber - The world's fastest | growing real-time communications platform! Don't just IM. Build it | in! http://www.jabber.com/osdn/xim | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: <jc...@fe...> - 2002-07-25 01:53:09
|
On Wednesday 24 July 2002 23:04, Maurice LeBrun wrote: | Jo=E3o Cardoso writes: =2E.. | > As I told before, suse-7.2 don't have tkInt.h and other tkInt.h | > dependent header files. | | It's not in the default Tcl/Tk tarball install either. What | exactly is needed from these files? If it's just function | prototypes, then no problem, just compile without all the prototypes | in place. You can do configure magic to use them *if* found. OTOH, | if what you need is a structure definition, then the problem is | harder to work around. Yes, it looks like tkwin needs the definition of a internal structure. Vince, that is only needed once in the tkwin code, can't it be done=20 using some tk utility function? Another issue: I dont like the name tkwin for the new driver: we=20 already have a tk driver and a xwin driver. As the tkwin driver main=20 purpose is to be cross platform capable, couldn't it be called tkx? or=20 xtk? or tkall? The directory name in the bindings directory is already=20 called tk-x-plat... Joao | | > Trying to follow the the tkwin receipt gives: | > | > [jcard@feup] wish | > % load libplplotd.so.5.1.0 Plplotter | > couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: | > cannot open shared object file: No such file or directory | > | > % load libplplotd.so Plplotter | > couldn't find procedure Plplotter_Init | > ... | | I've been unable to get this stuff to work either. |
From: Vince D. <vi...@sa...> - 2002-07-25 08:29:28
|
On Thu, 25 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > Yes, it looks like tkwin needs the definition of a internal structure. >=20 > Vince, that is only needed once in the tkwin code, can't it be done=20 > using some tk utility function? I don't believe so. I'll take another look, however. > Another issue: I dont like the name tkwin for the new driver: we=20 > already have a tk driver and a xwin driver. As the tkwin driver main=20 > purpose is to be cross platform capable, couldn't it be called tkx? or=20 > xtk? or tkall? The directory name in the bindings directory is already=20 > called tk-x-plat... I don't like anything like 'tkx' because that sounds like it is 'tk on X windows' which it is explicitly *not* (that is what the old 'tk' driver is). If anything we should rename 'tk' to 'tkx' and take 'tk' for the new driver *grin*. Vince. |
From: Vince D. <vi...@sa...> - 2002-07-25 11:31:47
|
>Vince, that is only needed once in the tkwin code, can't it be done >using some tk utility function? Actually, I think there may be a way --- get rid of that function completely (PlPlotterKeyEH) and replace it with some simple Tcl code: Something like: bind Plframe Left "plframekey %w -1 0 %X %Y" proc plframekey {pl xdiff ydiff xroot yroot} { # fill in tcl/tk code to warp the pointer to the new position } ?? -- Vince <http://www.santafe.edu/~vince> |
From: Alan W. I. <ir...@be...> - 2002-07-24 22:12:14
|
On Wed, 24 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Saturday 20 July 2002 00:40, Alan W. Irwin wrote: > ... > | > | I believe this new linking scheme should work for all modern Linux > | dynamic loaders. > > This doesn't mean that others unices will be forgeted, does it? Yes, they will be taken care of eventually. The ideal way to do this is with libtool. I looked fairly hard at the libtool documentation, and I was strongly tempted to go ahead with it because it looks quite straightforward= =2E However, I ultimately decided to wait for Rafael (in the fall at the earliest according to his latest communication) since libtool is now highly integrated with automake, and automake brings in other complications. By the way the libtool documentation covers the case where one library is linked to others. The long chain of shared libraries idea (which I am trying here) will probably only work on linux, but if you specify the chain clearly to libtool, it will automatically do what is necessary for all othe= r Unix architectures with semi-broken loaders that do not support a chain of shared libraries. So getting the library dependencies right on Linux is work that ultimately will benefit all Unix architectures once we move to libtool. > > | (Just for the record, my dynamic loader > | /lib/ld-2.2.5.so from Debian woody is part of the libc6-2.2.5 > | package.) However, if I recall correctly there was some evidence in > | the past that Joao's older patched SuSe distribution had different > | linking requirements. So Joao and others, please test the latest CVS > | on your various Linux distributions starting from a fresh checkout > | from CVS. > > As I told before, suse-7.2 don't have tkInt.h and other tkInt.h > dependent header files. > Copying those from the source tarball to /usr=09/include enables the > compilation of the tkwin driver, but not running it in plplot tmp dir: > > [jcard@feup] ./x01c -dev tkwin > Plplot library version: 5.1.0 > No tk plframe widget to connect to tkwin has no standalone mode so that is the correct message, and because you got that message rather than a missing library problem, it looks like the linking is correct for that application on your system. > [jcard@feup] wish > % load libplplotd.so.5.1.0 Plplotter > couldn't load file "libplplotd.so.5.1.0": libplplotd.so.5.1.0: cannot > open shared object file: No such file or directory [...] > It seems that some path is missing. > Coull you please send an updated receipt? I'm afraid that I have not > fully following the tkwin thread. It's in plplot/examples/tk/README.tkdemos > > Also, > [jcard@feup] ./x01c -dev tk > Plplot library version: 5.1.0 > > gives the following error message in a tk window: > Invalid command name "plw::create" > while executing > "plw::create .x01c tk" > ("after" script) > > This also appeared in some messages in the list, but I can't see how to > solve it. Did you start from a clean checkout? Also, try again from a freshly invoke= d xterm. I did get some weird interaction with xterms after a few days that = I could not solve except by exiting the xterm and starting over. In plplot/tm= p you should need no special environment variables set. > > Finally, the libplplot_tkwin_driverd.so and libplplot_xwin_driverd.so: > what are they for? libpltcl needs to link to these. > I think that they are there to help the unix loader to find the > xxx_drv.so files, but it does not look a clean approach to the > problem... There are two issues here. (1) the driver dll's are not named in the stand= ard form libxxxxx.so which means you cannot use the -L and -l options on the l= ink line to find them. Instead, your only recourse is to specify full pathname/libraryname. (2) the driver dll's are in their own directory so a= t run time you have to refer specifically to that directory or do the -rpath equivalent. I solved both issues by making symlinks. Let me know if there is some better approach to solve issues (1) and (2). > perhaps the drivers that know that they will need another > driver should ldopen() them themselfs? As far as I know, no driver depends on anything in other drivers so that should not be an issue. To clarify it is libpltcl that uses symbols and functions defined in xwin.c (and tkwin.c), and also, as is quite natural, we have xwin.c and tkwin.c also using symbols/functions from libpltcl. It is this cross-linking that is the cause of all the linking troubles we had before, and libtools specifically warns against cross-linking like this. I got out of these cross-linking troubles by using chain linking (where the linux loader is smart enough to make available all symbols in the chain), but that only works on Linux. So ultimately if we want dynamic drivers to work on other architectures I believe we have to clearly separate libpltcl and the driver= s by moving some functions and/or symbols from the drivers to the library, i.e., by splitting xwin.c into xwin.c and a xwin_helper.c (say) where the latter goes into the pltcl library and calls nothing in xwin.c. Joao, would splitting xwin.c like this be straightforward? Alan |
From: <jc...@fe...> - 2002-07-25 01:44:31
|
On Wednesday 24 July 2002 23:11, Alan W. Irwin wrote: | On Wed, 24 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Saturday 20 July 2002 00:40, Alan W. Irwin wrote: | > ... | > | > | I believe this new linking scheme should work for all modern | > | Linux dynamic loaders. | > | > This doesn't mean that others unices will be forgeted, does it? | | Yes, they will be taken care of eventually. The ideal way to do | this is with libtool. I looked fairly hard at the libtool | documentation, and I was strongly tempted to go ahead with it | because it looks quite straightforward. However, I ultimately | decided to wait for Rafael (in the fall at the earliest according to | his latest communication) since libtool is now highly integrated | with automake, and automake brings in other complications. OK. A strong point of PLplot is it cross-platform capability, so don't=20 let us forget brothers in place of near cousins :-? By the way, Plplot will very probably be used in a 2nd year programming=20 discipline at my faculty, under C and MS-DOS, so be ready to answer a=20 lot of questions and provide support. | > [jcard@feup] ./x01c -dev tkwin | > Plplot library version: 5.1.0 | > No tk plframe widget to connect to | | tkwin has no standalone mode Ah. But this can be corrected, I think. After all the tk driver is both=20 a "standalone" driver and can also be invoked directly from a wish, so=20 tkwin should be able to do it also. Probably the only needed thing=20 will be to invoke at tkwin startup a tcl script to setup the plframe=20 etc, as the tk driver does? A related issue: at the end of 'configure', there is a small "error":=20 as far as I understand it, the "enable_xxx" lines refer to bindings,=20 not to drivers, so the enable_xwin is not correct, and the=20 enable_tkwin is in a limbo, because it is not yet a driver (no=20 standalone mode), nor specifically a binding -- tk is both a driver=20 and together with tcl provides bindings: enable_xwin: yes enable_tcl: no enable_tk: yes enable_itcl: no enable_cxx: no enable_python: no enable_f77: no enable_java: no enable_octave: no enable_gnome: no enable_tkwin: no =2E.. | > Also, | > [jcard@feup] ./x01c -dev tk | > Plplot library version: 5.1.0 | > | > gives the following error message in a tk window: | > Invalid command name "plw::create" | > while executing | > "plw::create .x01c tk" | > ("after" script) | > | > This also appeared in some messages in the list, but I can't see | > how to solve it. | | Did you start from a clean checkout? Also, try again from a | freshly invoked xterm. I did get some weird interaction with xterms | after a few days that I could not solve except by exiting the xterm | and starting over. In plplot/tmp you should need no special | environment variables set. Nope... don't work. The xterm issue must be related with environment variables from=20 previous experiences. | > Finally, the libplplot_tkwin_driverd.so and | > libplplot_xwin_driverd.so: what are they for? | | libpltcl needs to link to these. OK, but why? | > I think that they are there to help the unix loader to find the | > xxx_drv.so files, but it does not look a clean approach to the | > problem... | | There are two issues here. (1) the driver dll's are not named in | the standard form libxxxxx.so which means you cannot use the -L and | -l options on the link line to find them. Instead, your only | recourse is to specify full pathname/libraryname. That's why they are dlopened, instead of just being dropped in a=20 directory automatically searched by the unix loader (directories that=20 can be specified in /et=09c/ld.so.conf---but only root can do it) | (2) the driver | dll's are in their own directory so at run time you have to refer | specifically to that directory or do the -rpath equivalent. I | solved both issues by making symlinks. Let me know if there is some | better approach to solve issues (1) and (2). | | > perhaps the drivers that know that they will need another | > driver should ldopen() them themselfs? | | As far as I know, no driver depends on anything in other drivers so | that should not be an issue. This is a bit complex, but finds that there are three symbols in=20 libpltcl that are resolved in xwin_drv: jcard:~/tmp/plplot/tmp > for i in `nm -p libpltcl.so | fgrep " U "| awk=20 '{print $2}'`; do nm -p drivers/xwin_drv.so | fgrep $i | fgrep " T ";=20 done 00004900 T plX_setBGFG 00005550 T PLColor_from_XColor 00001d40 T plD_open_xw Thus, you have solved the problem of tk_drv depending on xwin_drv by=20 moving the problem to libpltcl. Now is libpltcl that depends on the=20 xwin driver. I don't think this to be nice---I would accept a driver=20 that depends on another driver, but a library that depends on a driver=20 is not good design. This is why I gave up in creating a libpltcl.=20 Why don't I read it until the end first? :( | To clarify it is libpltcl that uses symbols and functions defined | in xwin.c (and tkwin.c), and also, as is quite natural, we have | xwin.c and tkwin.c also using symbols/functions from libpltcl. It | is this cross-linking that is the cause of all the linking troubles | we had before, and libtools specifically warns against cross-linking | like this. I got out of these cross-linking troubles by using chain | linking (where the linux loader is smart enough to make available | all symbols in the chain), but that only works on Linux. So | ultimately if we want dynamic drivers to work on other architectures | I believe we have to clearly separate libpltcl and the drivers by | moving some functions and/or symbols from the drivers to the | library, i.e., by splitting xwin.c into xwin.c and a xwin_helper.c | (say) where the latter goes into the pltcl library and calls nothing | in xwin.c. | | Joao, would splitting xwin.c like this be straightforward? I think that the correct approach would be to remove the dependencies=20 that tk_drv has on xwin_drv. xwin_drv does not depend on anything (but=20 xlib). Then, one would have a libpltcl with symbols needed by tk only, and=20 xwin would not depend on nothing. Further, libpltcl (I would call it=20 libpltcltk) would be linked alone with user programs that use tcl/tk;=20 when the user program tries to open the tk driver, the missing symbols=20 in tk_drv would be found in the already (user) loaded library. And now the good news: tkwin_drv does not depends on xwin_drv! If this=20 was done, it can be done with tk_drv also! I don't know how, to be=20 sure... only the person who wrote the tk driver knows why he did it=20 and how to break the dependency. This is the right track to follow: the user program (plserver,=20 plrender, x01c, e.g.) depends on libplplot only: "cc foo.c -o foo=20 -lplplot" If the user uses xwin, then libplplot will dlopen it; if the user uses tk, then libplplot will dlopen it, and tk_drv will=20 dlopen libpltcl. I'm not sure what to do with Tk user programs written in C: should they=20 link with libpltcl? "cc tk_foo.c -o tk_foo -lpltcl -lplplot"=20 The issue is: does libpltcl provide some user functionalities, and as=20 such it should be linked with the user program, or is just needed by=20 tk_drv, and in this case it is just an auxiliary library that could be=20 dropped in the drivers directory and dlopened by tk_drv? I don't know. I think that the effort that Alan did is meritorious and should be=20 continued, but in my opinion it can only be successfull with the help=20 of the "seniors" members who wrote the tk driver. Did anybody hear=20 this :-) Joao |
From: Alan W. I. <ir...@be...> - 2002-07-25 06:20:19
|
On Thu, 25 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Wednesday 24 July 2002 23:11, Alan W. Irwin wrote: > | tkwin has no standalone mode > > Ah. But this can be corrected, I think. After all the tk driver is both > a "standalone" driver and can also be invoked directly from a wish, so > tkwin should be able to do it also. Probably the only needed thing > will be to invoke at tkwin startup a tcl script to setup the plframe > etc, as the tk driver does? > > A related issue: at the end of 'configure', there is a small "error": > as far as I understand it, the "enable_xxx" lines refer to bindings, > not to drivers, so the enable_xwin is not correct, and the > enable_tkwin is in a limbo, because it is not yet a driver (no > standalone mode), nor specifically a binding -- tk is both a driver > and together with tcl provides bindings: > > enable_xwin: yes enable_tcl: no > enable_tk: yes enable_itcl: no > enable_cxx: no enable_python: no > enable_f77: no enable_java: no > enable_octave: no enable_gnome: no > enable_tkwin: no > ... Hmmm. I put that in there because it was already done for xwin, but I don't care if you want to remove both. But you should probably remove gnome from this list as well since that is also just a driver. > | As far as I know, no driver depends on anything in other drivers so > | that should not be an issue. > > This is a bit complex, but finds that there are three symbols in > libpltcl that are resolved in xwin_drv: > > jcard:~/tmp/plplot/tmp > for i in `nm -p libpltcl.so | fgrep " U "| awk > '{print $2}'`; do nm -p drivers/xwin_drv.so | fgrep $i | fgrep " T "; > done > 00004900 T plX_setBGFG > 00005550 T PLColor_from_XColor > 00001d40 T plD_open_xw > > Thus, you have solved the problem of tk_drv depending on xwin_drv by > moving the problem to libpltcl. You mention tk_drv, but I don't think that was ever the problem. Instead, *libplplot* was depending on xwin_drv before, and I separated out that part into the much smaller libpltcl where I hope we can concentrate on the problem and fix it. By the way, I don't claim to understand exactly what you did above with bash, but I believe you when you come to the conclusion that there are only 3 symbols in libpltcl.so that are resolved by xwin_drv.so. Only 3 symbols encouraged me to look further for a solution o= f the cross-linking problem. To solve the problem, I believe all we have to do is split out plX_setBGFG, PLColor_from_XColor, plD_open_xw, GetVisual, and AllocBGFG from the xwin.c file into xwin_helper.c. The last two are called by plD_open_xw, but as far as I can tell, none of these functions refer to anything else in xwin.c. S= o if I am right, putting xwin_helper.c into libpltcl resolves the 3 symbols above and introduces no new ones that depend on the remaining xwin.c. Thus= , this proposed splitting completely resolves the cross-linking problem. If you agree, would you be willing to do that splitting? (It would take me substantially longer because I don't have your C skills, and in any case somebody should check that I am right about the proposed xwin_helper.c containing no calls to functions inside xwin.c.) > > I think that the correct approach would be to remove the dependencies > that tk_drv has on xwin_drv. Actually tk_drv is fine (as I believe you realized later in your e-mail), i= t is libpltcl that has the 3 symbols above that are resolved by xwin, and which the proposed splitting of xwin should fix. > xwin_drv does not depend on anything (but > xlib). Actually, like all drivers, xwin has calls to libplplot core functions (and in my proposed splitting solution above there would also be calls to functions in libpltcl including the ones in xwin_helper.c that would be mad= e part of libpltcl.) > (I would call it libpltcltk) That's probably a better name. I will change it unless somebody has even a better suggestion. > would be linked alone with user programs that use tcl/tk; > when the user program tries to open the tk driver, the missing symbols > in tk_drv would be found in the already (user) loaded library. The current solution does this with a long linked list of libraries and depending on the Linux loader to keep track of all the symbols no matter in what order they are linked, but your comment and one by Vince convinces me there is a more logical way to do the linking so that every library that depends on another library will be linked to that library. Also I think thi= s change is essential for the libtool method to eventually work in a cross-platform way. So in my proposed new linking scenario (assuming splitting off xwin_helper works like I think it will, and assuming something similar will work for tkwin_helper), there will be no cross-linking issues. (All the dependencie= s of libraries will be one-way only.) The distinction between special and ordinary dyndrivers will be gone. All the dyndrivers will link to (depend on) libplplot, some of them will also link to libpltcltk, and some of them will also link to special libraries such as libX11, libgd, etc. libplplot will link to nothing since it actually depends on nothing else. libpltcltk will link to libplplot and libtclmatrix. Ordinary applications like x01c would then link to just libplplot. Using say the xwin driver from an ordinary application would dynamically load the xwin driver which in turn would make everything available from libpltcltk (the xwin_helper.c function= s and other functions) since the xwin driver was linked to that library. And similarly for the tk driver. Special applications such as pltcl and plserve= r would be linked to libpltcltk as well as libplplot since those applications depend directly on functions in both libraries. Comments requested on the new linking proposal (especially on my idea of splitting xwin.c to get rid of the cross-linking issue). Alan |
From: Vince D. <vi...@sa...> - 2002-07-25 08:35:03
|
> | As far as I know, no driver depends on anything in other drivers so > | that should not be an issue. This is untrue of the 'tk' driver. While I am sure it is possible to remove any link-time dependencies through use of appropriate stubs, dispatch tables etc, actually using the tk driver uses the 'plframe' widget which in turn *requires* the xwin driver to operate. Therefore it is meaningless to talk about the 'tk' driver unless the 'xwin' driver is available... (at least that's how I understand it). In this respect the new 'tkwin' driver is better -- it just depends on external things (availability of tcl/tk). -- Vince <http://www.santafe.edu/~vince> |
From: Alan W. I. <ir...@be...> - 2002-07-25 15:51:37
|
On Thu, 25 Jul 2002, Vince Darley wrote: > > | As far as I know, no driver depends on anything in other drivers so > > | that should not be an issue. > > This is untrue of the 'tk' driver. While I am sure it is possible to > remove any link-time dependencies through use of appropriate stubs, > dispatch tables etc, actually using the tk driver uses the 'plframe' > widget which in turn *requires* the xwin driver to operate. Therefore it > is meaningless to talk about the 'tk' driver unless the 'xwin' driver is > available... > > (at least that's how I understand it). That may be true, but I think the dependency is indirect via a library. From my experiments, tk does not depend explicitly on any other driver. I decided to check that empirical result using this adaptation of Joao's bash commands for i in nm -p drivers/tkd_drv.so | fgrep " U "| awk '{print $2}'; do nm -p \ drivers/xwind_drv.so | fgrep $i | fgrep " T "; done there was no output which indicates there are no symbols in xwin_drv that resolve undefined symbols in tk_drv. Instead, as is natural, tk does depend on libplplot, and I presume it also depends on libpltcltk (although I haven't checked). Where we have to break the vicious circle is to stop libraries depending on any drivers, and I believe moving the 5 functions from xwin_drv to libpltcktk along the lines I suggested will do the trick. That brings up the similar question for tkwin.c. Currently we have in complete analogy with the xwin.c case, the following bad situation: for i in nm -p libpltcld.so | fgrep " U "| awk '{print $2}'; do nm -p \ drivers/tkwind_drv.so | fgrep $i | fgrep " T "; done 000030f0 T PLColor_from_TkColor_Changed 00001804 T plD_open_tkwin 00002cb0 T pltkwin_setBGFG As with xwin.c, I believe the solution here is to split out these functions from tkwin.c into another file (tkwin_helper.c, say) whose compiled object will go into libpltcltk. I also notice that plD_open_tkwin calls GetVisual and AllocBGFG which are defined locally in tkwin.c in direct analogy with plD_open_tkwin which calls its versions of these locally defined functions in xwin.c. Vince, are these tkwin-defined versions of GetVisual and AllocBGFG identical to the xwin definitions? If so, when the 3 xwin.c functions are split out, they would be able to use GetVisual and AllocBGFG already defined in xwin_helper.c and put into libpltcltk as part of my proposal. If the tkwin versions of GetVisual and AllocBGFG are different from the xwin versions then we would have to split them out also and give them different names to avoid a name clash. I emphasize all these tkwin.c splitting ideas are simply to give you food for thought for now. All of this is vaporware until we prove that splitting *xwin.c* solves the cross-linking problem in that case. But currently it looks like there is complete analogy between the xwin and tkwin cases so if we find a solution for xwin, the solution for tkwin will soon follow. Alan |
From: Alan W. I. <ir...@be...> - 2002-07-25 20:38:08
|
Later I will discuss the xwin.c split I have done, but first I should deal with two errors in my last message to the list. First OOPS (which shows my C inexperience). If we keep static void GetVisual (PLStream *pls); static void AllocBGFG (PLStream *pls); in both xwin_common.c (note new name which I have decided I like better than xwin_helper.c) and tkwin_common.c, then there is no name clash and everybody is happy. Second OOPS: my jed editor dropped the backwards quotes from my bash command line when I cut and pasted. Here are the actual bash commands. for i in `nm -p drivers/tkd_drv.so | fgrep " U "| awk '{print $2}'`; do nm -p drivers/xwind_drv.so | fgrep $i | fgrep " T "; done That had no output. for i in `nm -p libpltcld.so | fgrep " U "| awk '{print $2}'`; do nm -p drivers/xwind_drv.so | fgrep $i | fgrep " T "; done That had an output of: 000030f0 T PLColor_from_TkColor_Changed 00001804 T plD_open_tkwin 00002cb0 T pltkwin_setBGFG Now for the big news. I split xwin.c into xwin.c and xwin_common.c, put xwin_common.c into libpltcl (no name change yet), and removing the special driver treatment of xwin that I had before. All these changes seem to work well on Linux --enable-dyndrivers. For example, repeating Joao's bash command: for i in nm -p libpltcld.so | fgrep " U "| awk '{print $2}'; do nm -p drivers/xwind_drv.so | fgrep $i | fgrep " T "; done now has no result. Note I am still using the old linking model of a long chain of library dependencies so that libplplot pulls in everything else. But that only works on Linux so I intend to change this along the lines I mentioned. Note there are 7 functions in xwin_common.c which are two more than the 5 I found via visual inspection. But the additions are not very long so I think it is a good solution. Also, there was some trouble with plplot_ccmap, but I resolved that (probably in a clumsy way) by defining it statically in plxwd.h, and dropping the extern from plframe, and dropping the definition from xwin.c. So far I have done only extremely superficial testing of x01c -dev tk and wish in plplot/tmp, but they work fine so I urge everybody else to give this a try. If everybody is happy with this splitting, the next step is to do exactly the same to tkwin.c. 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 __________________________ |
From: <jc...@fe...> - 2002-07-26 05:02:46
|
On Thursday 25 July 2002 21:37, Alan W. Irwin wrote: =2E.. | Now for the big news. I split xwin.c into xwin.c and | xwin_common.c, put xwin_common.c into libpltcl (no name change yet), | and removing the special driver treatment of xwin that I had before. | All these changes seem to work well on Linux --enable-dyndrivers. | | For example, repeating Joao's bash command: | | for i in nm -p libpltcld.so | fgrep " U "| awk '{print $2}'; do nm | -p drivers/xwind_drv.so | fgrep $i | fgrep " T "; done | | now has no result. | | Note I am still using the old linking model of a long chain of | library dependencies so that libplplot pulls in everything else.=20 | But that only works on Linux so I intend to change this along the | lines I mentioned. | | Note there are 7 functions in xwin_common.c which are two more than | the 5 I found via visual inspection. But the additions are not very | long so I think it is a good solution. Also, there was some trouble | with plplot_ccmap, but I resolved that (probably in a clumsy way) by | defining it statically in plxwd.h, and dropping the extern from | plframe, and dropping the definition from xwin.c. | | So far I have done only extremely superficial testing of x01c -dev | tk and wish in plplot/tmp, but they work fine so I urge everybody | else to give this a try. | | If everybody is happy with this splitting, the next step is to do | exactly the same to tkwin.c. | | Alan I agree with the splitting of the xwin into another auxiliary driver to=20 be used by xwin_drv and tk_drv. That is the obvious solution, other=20 than just replicate the needed code into tk_drv. But I disagree in putting the common parts in libpltcl. Let's see, the tk driver is a driver that uses infrastructures from the=20 tcl/tk bindings and also happens to use the xwin driver; this last=20 ocurrence is an accident. Let us supose that the tk driver did'nt need=20 the xwin driver (1). But it needs the tcl/tk bindings infrastructure.=20 How should you design it? In my view, creating a library with the=20 tcl/tk infrastructure, libtcltk, and the driver itself, tk_drv. The tk=20 driver would need to be linked with the tcl/tk and xwin libraries, as=20 other drivers do (and also to libtcltk, more on this latter). This is similar to what happens with other drivers. Of course all=20 drivers depends on libplplot. Now about the bindings. Bindings require a library that the user=20 program must be linked with (and with libplplot also). That's why=20 there is a libcxx and should exist a libf77. This is for compiled=20 languages, as for interpreted languages one generaly has run time=20 loading, such as plplot_octave.oct for Octave and plmodule.so for=20 Python. And for mixed drivers/bindings? Lets take the incomplete gnome driver.=20 It already has a driver, but gnome users would like to have a library,=20 say libplgnome, to link theirs programs with. This is an hipotetical=20 example. Now, finally, following the above "philosophy", the tk driver/bindings=20 should have a library that users programs links with, and a driver,=20 that could need to be linked with that library. Examples of tk user=20 programs are plserver, pltcl, plrender, etc. Thus they should need to=20 be linked with libtcltk. The tcl/tk bindings also has another library,=20 libtclmatrix, that is needed by the bindings but that was considered=20 to be of general usage, and as such was keept in a separated library. =20 The driver itself could be linked, or not, with libtcltk (but it=20 needs). Ideally, if some functions in libpltcltk are only needed by=20 the driver, than they should not go into libpltcltk, but make part of=20 the driver (a multi-file driver), but this would be too complicated by=20 now. The fact that tk_drv *needs* , by design, xwin_drv, is no obstacle to=20 this reasoning. So, to finish this rather long talk, how do I see that the problem=20 should be solved? a libtcltk library in the tmp directory, and a=20 tk_drv, a xwin_drv, and a tkxwin_drv, all in the drivers subdirectory.=20 In plD_init_tk() and plD_init_xw(), the tkxwin_drv file would be=20 dlopened to provide the common funcionalities. Not in a library! Unfortunatelly I don't have the time to further work (talk would be=20 more correct) on this. I will reply to the other e-mails tomorrow. Jo=E3o |
From: Alan W. I. <ir...@be...> - 2002-07-26 07:58:23
|
On Fri, 26 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Thursday 25 July 2002 21:37, Alan W. Irwin wrote: > | If everybody is happy with this splitting, the next step is to do > | exactly the same to tkwin.c. > > I agree with the splitting of the xwin into another auxiliary driver to > be used by xwin_drv and tk_drv. That is the obvious solution, other > than just replicate the needed code into tk_drv. > > But I disagree in putting the common parts in libpltcl. > > Let's see, the tk driver is a driver that uses infrastructures from the > tcl/tk bindings and also happens to use the xwin driver..... Joao, your argument is based on the assumption that the code in tk.c (the strict definition of what is meant by the tk driver) happens to use the xwi= n driver, and that assumption is not correct at all! Certainly, the tcl/tk bindings (as opposed to the tk driver) used functions defined in the old xwin driver, but even that is now no longer the case. To clarify the actual situation, the old problem was that libplplot itself contained the tcl/tk bindings (in particular plframe.c) that had symbols th= at were resolved by xwin.c. If you look at the 3 symbols you found by your ingenious bash line; plX_setBGFG, PLColor_from_XColor, and plD_open_xw; in every case it was plframe.c (not tk.c!) that had calls to those 3 functions defined in the old xwin.c, and this was the source of all the previous linking trouble. That linking trouble is now cured by splitting out xwin_common.c. Note my goal was *not* to redesign the tk driver. Instead my goal was something much simpler; to make sure that no library would depend on functions defined in driver code. The side benefit of this cross-dependenc= y elimination was that the tcl/tk *binding* would be better organized. I hav= e now achieved these goals by removing xwin_common.c from xwin.c. The point is the functions defined in xwin_common.c are referred to *both* by the new xwin.c and plframe.c. So the simple solution that breaks the prior cross-dependency between the plplot libraries and xwin is to put xwin_common.o and the plframe.o code that refers to it in the same library. I don't care what that library is called, but it made sense to me to put everything else in there that was concerned with the tcl/tk binding. Once I get the linking reorganized into my new scheme that library (lets call it libpltcltk for now) will be linked to both libplplot and libtclmatrix. Thus, loading libpltcltk from wish should just work. The load command under wish dlopens libpltcltk and becaus= e of the way that library will be linked in the new scheme, that dlopen shoul= d drag in libplplot and libtclmatrix as well. That wish situation is exactly parallel to what happens in the python case so my simple goal of making sur= e no library code called functions defined in driver code and the soon to be implement change to the new linking scheme should satisfy concerns we have both expressed before about the way the tcl/tk bindings were organized. Dropping the topic of the tcl/tk binding and moving back to the tk driver topic, in the proposed new linking scheme, the tk driver simply links to libplplot and libpltcltk just like the xwin driver, *but completely independent of that driver* contrary to what you seemed to say above. Under that scenario when the libplplot dynamic driver code dlopens the tk driver, libplplot will already be loaded, libpltcltk will be automatically loaded because of the way that the tk driver was linked, and beyond that libtclmatrix will be automatically loaded because of the way that libpltclt= k was linked. I think this is a very nice way to do things in Linux. Lookin= g beyond that if we keep this basic organization for libtool and its dlopen handler, we can get the same functionality cross-platform. If there are no further objections I would like to split tkwin.c and move t= o the new linking scenario (which is not that different from the present chai= n linking scenario) early tomorrow and then give you guys the weekend (when I will be largely out of e-mail contact) to hammer it to make sure it all works for your various Linux distributions. Alan |
From: <jc...@fe...> - 2002-07-27 01:21:34
|
On Friday 26 July 2002 08:58, Alan W. Irwin wrote: | On Fri, 26 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Thursday 25 July 2002 21:37, Alan W. Irwin wrote: | > | If everybody is happy with this splitting, the next step is to | > | do exactly the same to tkwin.c. | > | > I agree with the splitting of the xwin into another auxiliary | > driver to be used by xwin_drv and tk_drv. That is the obvious | > solution, other than just replicate the needed code into tk_drv. | > | > But I disagree in putting the common parts in libpltcl. | > | > Let's see, the tk driver is a driver that uses infrastructures | > from the tcl/tk bindings and also happens to use the xwin | > driver..... | | Joao, your argument is based on the assumption that the code in | tk.c (the strict definition of what is meant by the tk driver) | happens to use the xwin driver, and that assumption is not correct | at all! Certainly, the tcl/tk bindings (as opposed to the tk | driver) used functions defined in the old xwin driver, but even that | is now no longer the case. No. It does not matter where the code that makes tk_drv is. The tk driver uses a plframe, wich is a tk plot widget built=20 specifically for plplot. The plframe should be considered part of the=20 tcl/tk bindings, as it is just one more tk widget. The plframe is=20 created in plframe.c, and in plframe.c:plFrameCmd() the xwin driver is=20 deliberatily opened: /* Partially initialize X driver. */ plD_open_xw(plFramePtr->pls); Further, plframe.c says: This module implements "plframe" widgets for the Tk toolkit.=20 These are frames that have extra logic to allow them to be interfaced with the PLplot X driver. These are then drawn into and respond to keyboard and mouse events. To say it another way: the gnome driver uses a gnome plot widget that=20 Rafael did not have to write it, as Maurice did with the tk plframe. The gnome driver links with gnome libraries, the tk driver has to link =20 with the library where the plframe is and with tcl/tk libs. Of course there is not a clear cut distintion in the tk case, as the=20 bindings make no sense without the tk driver and vice-versa. | To clarify the actual situation, the old problem was that libplplot | itself contained the tcl/tk bindings (in particular plframe.c) that | had symbols that were resolved by xwin.c. If you look at the 3 | symbols you found by your ingenious bash line; plX_setBGFG, | PLColor_from_XColor, and plD_open_xw; in every case it was plframe.c | (not tk.c!) that had calls to those 3 functions defined in the old | xwin.c, and this was the source of all the previous linking trouble. | That linking trouble is now cured by splitting out xwin_common.c. | | Note my goal was *not* to redesign the tk driver. Instead my goal | was something much simpler; to make sure that no library would | depend on functions defined in driver code. The side benefit of | this cross-dependency elimination was that the tcl/tk *binding* | would be better organized. I have now achieved these goals by | removing xwin_common.c from xwin.c. The point is the functions | defined in xwin_common.c are referred to *both* by the new xwin.c | and plframe.c. | | So the simple solution that breaks the prior cross-dependency | between the plplot libraries and xwin is to put xwin_common.o and | the plframe.o code that refers to it in the same library. As I said before, I agree with the splitting, but I do not agree in=20 puting xwin_common in libtcltk. It *is not* and *should not* be part=20 of a tcl/tk library! xwin_common functions has nothing to do (only by=20 accident, not design) with tcl/tk nor the tk driver. The reverse is=20 true, the tk driver was designed as is. And what happens if someone does not want/has tck/tk but still wants=20 the xwin driver? Do we have to build a libtcltk with only=20 xwin_common.o as the only object file? No, you can't convince me. The right track is to put if (!dlopen ("<path?>/xwin_common_drv.so", RTLD_LAZY)) exit(1); in both xwin.c and tk.c at plD_init_xx, and to put xwin_commo_drv.so in=20 the same directory as the other drivers. | I don't | care what that library is called, but it made sense to me to put | everything else in there that was concerned with the tcl/tk binding. Yes, but not what was not been written/designed to be there. | Once I get the linking reorganized into my new scheme that library | (lets call it libpltcltk for now) will be linked to both libplplot | and libtclmatrix. Thus, loading libpltcltk from wish should just | work. The load command under wish dlopens libpltcltk and because of | the way that library will be linked in the new scheme, that dlopen | should drag in libplplot and libtclmatrix as well. That wish | situation is exactly parallel to what happens in the python case so | my simple goal of making sure no library code called functions | defined in driver code and the soon to be implement change to the | new linking scheme should satisfy concerns we have both expressed | before about the way the tcl/tk bindings were organized. | | Dropping the topic of the tcl/tk binding and moving back to the tk | driver topic, in the proposed new linking scheme, the tk driver | simply links to libplplot and libpltcltk just like the xwin driver, Ah! the xwin driver links with libtcltk! doesn't that sounds strange to=20 you? | *but completely independent of that driver* contrary to what you | seemed to say above. I was not talking on linking requirements but on design considerations. | Under that scenario when the libplplot dynamic | driver code dlopens the tk driver, libplplot will already be loaded, | libpltcltk will be automatically loaded because of the way that the | tk driver was linked, and beyond that libtclmatrix will be | automatically loaded because of the way that libpltcltk was linked.=20 | I think this is a very nice way to do things in Linux. Looking | beyond that if we keep this basic organization for libtool and its | dlopen handler, we can get the same functionality cross-platform. And what about this? at plinit() the driver is ldopened() in=20 plLoadDriver(), and at plD_init_tk() the driver=20 dlopen("xwin_common.so",...)? Both libplplot and libtcltk where specified in the link command, and=20 thus are available, and libtclmatrix was specified as a requirement=20 when libtcltk was built, and as such will be loaded. | If there are no further objections I would like to split tkwin.c | and move to the new linking scenario (which is not that different | from the present chain linking scenario) early tomorrow and then | give you guys the weekend (when I will be largely out of e-mail | contact) to hammer it to make sure it all works for your various | Linux distributions. It will work. But it is not a good design. As a matter of fact it was=20 not designed, it just works. | | Alan |
From: Alan W. I. <ir...@be...> - 2002-07-27 07:43:48
|
On Sat, 27 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Friday 26 July 2002 08:58, Alan W. Irwin wrote: > | Joao, your argument is based on the assumption that the code in > | tk.c (the strict definition of what is meant by the tk driver) > | happens to use the xwin driver, and that assumption is not correct > | at all! Certainly, the tcl/tk bindings (as opposed to the tk > | driver) used functions defined in the old xwin driver, but even that > | is now no longer the case. > > No. It does not matter where the code that makes tk_drv is. Sorry, Joao, but I cannot agree at all with that statement. Where the code is located (i.e., what file) is the primary consideration for whether the linking works or not. > > The tk driver uses a plframe, wich is a tk plot widget built > specifically for plplot. The plframe should be considered part of the > tcl/tk bindings, as it is just one more tk widget. The plframe is > created in plframe.c, and in plframe.c:plFrameCmd() the xwin driver is > deliberatily opened: > /* Partially initialize X driver. */ > plD_open_xw(plFramePtr->pls); > > Further, plframe.c says: > This module implements "plframe" widgets for the Tk toolkit. > These are frames that have extra logic to allow them to be > interfaced with the PLplot X driver. These are then drawn into > and respond to keyboard and mouse events. > > To say it another way: the gnome driver uses a gnome plot widget that > Rafael did not have to write it, as Maurice did with the tk plframe. > The gnome driver links with gnome libraries, the tk driver has to link > with the library where the plframe is and with tcl/tk libs. And because of that design, plframe *must* link with xwin_common.o, i.e, xwin_common.o is absolutely essential to plframe. > I agree with the splitting, but I do not agree in > puting xwin_common in libtcltk. It *is not* and *should not* be part > of a tcl/tk library! > > And what happens if someone does not want/has tck/tk but still wants > the xwin driver? Do we have to build a libtcltk with only > xwin_common.o as the only object file? No, you can't convince me. It doesn't bother me a bit to have one quite specific configuration where xwin_common.o is the only thing that occurs in libtcltk. If you feel reall= y strongly about this, perhaps you could rename xwin_common.o to plframe_xwin_common.o? > > The right track is to put > > if (!dlopen ("<path?>/xwin_common_drv.so", RTLD_LAZY)) > exit(1); > > in both xwin.c and tk.c at plD_init_xx, and to put xwin_commo_drv.so in > the same directory as the other drivers. tk.c does not require a single function in xwin_common_drv.so so why are you suggesting it should dlopen it? > | Dropping the topic of the tcl/tk binding and moving back to the tk > | driver topic, in the proposed new linking scheme, the tk driver > | simply links to libplplot and libpltcltk just like the xwin driver, > > Ah! the xwin driver links with libtcltk! doesn't that sounds strange to > you? Not a bit. But if you are really bothered by it, we can call it the libtcltkxwin library. I believe what is fundamentally bothering you is the libpltcltk library as it now stands has several different uses. We could split that library again so that xwin_common.o is in its own library that i= s linked to both by libpltcltk and xwin, but at some point it is better to have miscellaneous uses for a library rather than the overhead of too many small libraries. It is a question of where you draw the line. Remember, xwin_common.c only has 500 lines of code spread amongst 7 small functions. For now, I am going to leave it in libpltcltk, but if somebody feels strongly enough to split it off into its own separate library, they can do so later. > > | *but completely independent of that driver* contrary to what you > | seemed to say above. > > I was not talking on linking requirements but on design considerations. Exactly. But we have to be practical. Linking requirements are essential for *any* design. > > | Under that scenario when the libplplot dynamic > | driver code dlopens the tk driver, libplplot will already be loaded, > | libpltcltk will be automatically loaded because of the way that the > | tk driver was linked, and beyond that libtclmatrix will be > | automatically loaded because of the way that libpltcltk was linked. > | I think this is a very nice way to do things in Linux. Looking > | beyond that if we keep this basic organization for libtool and its > | dlopen handler, we can get the same functionality cross-platform. > > And what about this? at plinit() the driver is ldopened() in > plLoadDriver(), and at plD_init_tk() the driver > dlopen("xwin_common.so",...)? Again, it is plframe which needs xwin_common.o, *not* tk. It's the content of the files (plframe.c versus tk.c) that dictate whether the linking works or not. > > Both libplplot and libtcltk where specified in the link command, and > thus are available, and libtclmatrix was specified as a requirement > when libtcltk was built, and as such will be loaded. > > | If there are no further objections I would like to split tkwin.c > | and move to the new linking scenario (which is not that different > | from the present chain linking scenario) early tomorrow and then > | give you guys the weekend (when I will be largely out of e-mail > | contact) to hammer it to make sure it all works for your various > | Linux distributions. > > It will work. But it is not a good design. As a matter of fact it was > not designed, it just works. I will happily settle for something that works rather than the linking mess we had before that was keeping us from building dynamic versions of the tk, xwin, and tkwin drivers. Alan |
From: <jc...@fe...> - 2002-07-28 02:57:31
|
On Saturday 27 July 2002 08:43, Alan W. Irwin wrote: | On Sat, 27 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Friday 26 July 2002 08:58, Alan W. Irwin wrote: | > | Joao, your argument is based on the assumption that the code | > | in tk.c (the strict definition of what is meant by the tk | > | driver) happens to use the xwin driver, and that assumption is | > | not correct at all! Certainly, the tcl/tk bindings (as opposed | > | to the tk driver) used functions defined in the old xwin | > | driver, but even that is now no longer the case. | > | > No. It does not matter where the code that makes tk_drv is. | | Sorry, Joao, but I cannot agree at all with that statement. Where | the code is located (i.e., what file) is the primary consideration | for whether the linking works or not. | | > The tk driver uses a plframe, wich is a tk plot widget built | > specifically for plplot. The plframe should be considered part of | > the tcl/tk bindings, as it is just one more tk widget. The | > plframe is created in plframe.c, and in plframe.c:plFrameCmd() | > the xwin driver is deliberatily opened: | > /* Partially initialize X driver. */ | > plD_open_xw(plFramePtr->pls); | > | > Further, plframe.c says: | > This module implements "plframe" widgets for the Tk toolkit. | > These are frames that have extra logic to allow them to be | > interfaced with the PLplot X driver. These are then drawn | > into and respond to keyboard and mouse events. | > | > To say it another way: the gnome driver uses a gnome plot widget | > that Rafael did not have to write it, as Maurice did with the tk | > plframe. The gnome driver links with gnome libraries, the tk | > driver has to link with the library where the plframe is and with | > tcl/tk libs. | | And because of that design, plframe *must* link with xwin_common.o, | i.e, xwin_common.o is absolutely essential to plframe. tk_drv is also essencial, and is not linked. It is a driver. | > I agree with the splitting, but I do not agree in | > puting xwin_common in libtcltk. It *is not* and *should not* be | > part of a tcl/tk library! | > | > And what happens if someone does not want/has tck/tk but still | > wants the xwin driver? Do we have to build a libtcltk with only | > xwin_common.o as the only object file? No, you can't convince me. | | It doesn't bother me a bit to have one quite specific configuration | where xwin_common.o is the only thing that occurs in libtcltk. If | you feel really strongly about this, perhaps you could rename | xwin_common.o to plframe_xwin_common.o? It is not a matter of name, but where things should be and how they=20 should work. | > The right track is to put | > | > if (!dlopen ("<path?>/xwin_common_drv.so", RTLD_LAZY)) | > exit(1); | > | > in both xwin.c and tk.c at plD_init_xx, and to put | > xwin_commo_drv.so in the same directory as the other drivers. | | tk.c does not require a single function in xwin_common_drv.so so | why are you suggesting it should dlopen it? Come on! the tk driver needs the plframe, that needs the xwin driver!=20 And yes, I think that plframe.o should be part of the driver, and as=20 such linked with tk.o to make tk_drv. But the plframe only makes sense=20 with tclAPI, so should we link them all? No, if I configure with=20 --enable-tcl --disable-tk, than tclAPI.o will be built, plframe.o will=20 not, and I can use other driver then the tk_drv one. | > | Dropping the topic of the tcl/tk binding and moving back to | > | the tk driver topic, in the proposed new linking scheme, the tk | > | driver simply links to libplplot and libpltcltk just like the | > | xwin driver, | > | > Ah! the xwin driver links with libtcltk! doesn't that sounds | > strange to you? | | Not a bit. But if you are really bothered by it, we can call it the | libtcltkxwin library. I believe what is fundamentally bothering | you is the libpltcltk library as it now stands has several different | uses. Yes. I would say " several non-related uses". If you want to call it=20 libplmisc I would complain again. It is not the name, it is not the=20 linking, it is the fact that things can be done in another, cleaner=20 way. For example, tclMain.o is only used by pltcl -- why is it in the=20 library? why not link it only in the pltcl link command line? The same=20 for tkMain.o and pltk_Init.o, which are only used by plserver. The=20 same for plplotter_Init.o and plplotter.o, that are only used by=20 tkwin_drv. | We could split that library again so that xwin_common.o is in | its own library that is linked to both by libpltcltk and xwin, but | at some point it is better to have miscellaneous uses for a library | rather than the overhead of too many small libraries. It is a | question of where you draw the line. I agree. | Remember, xwin_common.c only | has 500 lines of code spread amongst 7 small functions. For now, I | am going to leave it in libpltcltk, but if somebody feels strongly | enough to split it off into its own separate library, they can do so | later. Things where OK when there was no dynamic drivers. All had to be put in=20 a single library. With dynamic drivers the core library is clean of=20 device dependent code. Bindings libraries (or loadable extensions) are=20 also free of device dependent code. Why should the tk driver be an=20 exception? Drivers should consist of a single source file, but=20 sometimes that is not practical, but that is not a reason to just=20 create another library. If it is a driver, or part of it, let it go to=20 the drivers directory. (my border line does not imply to put libplplot=20 in the drivers directory, as all drivers depend on it.) Strictly speaking, the only source file that should go to libtcl is=20 tclAPI.o. plframe.o, tcpip.o and plr.o are support files for the=20 plframe, that is used by the tk driver. Unfortunately the tk driver and the tcl bindings are all mixed=20 together, which makes my needs for regularity an impossible task. | > | *but completely independent of that driver* contrary to what | > | you seemed to say above. | > | > I was not talking on linking requirements but on design | > considerations. | | Exactly. But we have to be practical. Linking requirements are | essential for *any* design. | | > | Under that scenario when the libplplot dynamic | > | driver code dlopens the tk driver, libplplot will already be | > | loaded, libpltcltk will be automatically loaded because of the | > | way that the tk driver was linked, and beyond that libtclmatrix | > | will be automatically loaded because of the way that libpltcltk | > | was linked. I think this is a very nice way to do things in | > | Linux. Looking beyond that if we keep this basic organization | > | for libtool and its dlopen handler, we can get the same | > | functionality cross-platform. | > | > And what about this? at plinit() the driver is ldopened() in | > plLoadDriver(), and at plD_init_tk() the driver | > dlopen("xwin_common.so",...)? | | Again, it is plframe which needs xwin_common.o, *not* tk. It's the | content of the files (plframe.c versus tk.c) that dictate whether | the linking works or not. Again, it is the xwin drviver that needs xwin_common. That's for it=20 that is was written in the first place. The tk driver needs the xwin=20 driver. I'm talking of abstract things, not source files. | > Both libplplot and libtcltk where specified in the link command, | > and thus are available, and libtclmatrix was specified as a | > requirement when libtcltk was built, and as such will be loaded. | > | > | If there are no further objections I would like to split | > | tkwin.c and move to the new linking scenario (which is not that | > | different from the present chain linking scenario) early | > | tomorrow and then give you guys the weekend (when I will be | > | largely out of e-mail contact) to hammer it to make sure it all | > | works for your various Linux distributions. | > | > It will work. But it is not a good design. As a matter of fact it | > was not designed, it just works. | | I will happily settle for something that works rather than the | linking mess we had before that was keeping us from building dynamic | versions of the tk, xwin, and tkwin drivers. I consider this discussion closed for what concerns to me, and I will=20 not participate in it anymore. I do not however agree with the=20 implemented solution. And this was unfortunatelly a one-to-one man discussion, so I don't=20 know what others think. Thus this discussion is fruit-less. Joao | | Alan | | | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Vince D. <vi...@sa...> - 2002-07-29 16:30:21
|
>>> Come on! the tk driver needs the plframe, that needs the xwin driver! And yes, I think that plframe.o should be part of the driver, and as such linked with tk.o to make tk_drv. But the plframe only makes sense with tclAPI, so should we link them all? No, if I configure with --enable-tcl --disable-tk, than tclAPI.o will be built, plframe.o will not, and I can use other driver then the tk_drv one. >>> To throw in my 2 cents... I agree very much with the above. The plframe and tk.c are both parts of the tk driver. The fact one may be able to link one or other without the other is beside the point, and this means that the stuff which was in xwin.c is required by the tk driver (again whether one can link or not without it). The various 'plwidget.tcl' and related files are also effectively part of the tk driver (even though they aren't compiled, of cours). However, the 'pure-tcl' bindings (tclAPI.c) can be used completely independently (and in fact much of that code isn't even used by the tk driver --- one might wish to split that out into a common 'Plbasic_Init' used by Tcl AND tk bindings, and the 'Pltcl_Init' stuff whicvh is only used by the Tcl bindings (not Tk). cheers, -- Vince <http://www.santafe.edu/~vince> |