plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] xwin.c is now split

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > One possibility that might satisfy everyone, if it could work, is to use
 > an escape function in the xwin driver for the missing commands.  Then there
 > is separation without significant increase in work.  Has anyone looked into
 > this approach?

OK, I just did.  The three functions needed by plframe.c:

| 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 

can without too much trouble be called via the escape function approach, thus
removing them from consideration as external functions.  plX_setBGFG and
plD_open_xw don't even need to pass any data, just the stream pointer and an
operator index.  For PLColor_from_XColor, a pointer to a temporary structure
would have to be passed.  In each case, we're talking about only one call from
plframe.c, so the escape function approach seems reasonable to me.  Then the
whole issue with where to put these functions is avoided, and the xwin related
logic remains in xwin.c, very simple and effective.  So I'd like to go back
to the way it was but with these functions turned into escape functions.

Presumably this can be done with the tkwin_common.c stuff too.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

Joao: please read all of this before you comment....;-)

tkwin.c is now split into tkwin_common.c and tkwin.c following pretty
much what I did in the xwin_common.c and xwin.c case.

In direct analogy with the xwin_common case there was a plplot_tkwin_ccmap
definition that I had to deal with.  I probably did it in a clumsy way so
if anybody can come up with a better solution, please commit it (and
same remark about plplot_ccmap in the xwin_common case).  There may also
be some compiler warning issues, but I leave that to the C experts here
to fix up.

A separate tkwin_common.c is necessary because both plplotter.c and (the new)
tkwin.c depend on the functions defined in there.

Vince, I think the only practical difference this will make to you is you
have to deal with tkwin_common.c now.

Now on to the Linux library reorganization:

(1) It works! (which is quite important to me).  I have not done my complete
tests, but I did try the tk device from various front ends, and also pltcl,
plserver, and wish (all from plplot/tmp with LD_LIBRARY set to ./).

The wish recipe is now changed (as noted also in examples/tk/README.tkdemos.)

wish
source pldefaults.tcl
load libplplottcltkd.so Plplotter
package provide Plplotter 5.1.0
source runAllDemos.tcl

libplplotd will no longer work in that second line because of the
reorganized linking (see below), but this way is more logical in any case.

Vince, years ago when we first played with this I recall there was a
way to run tkdemos.tcl under wish and tcldemos.tcl under tclsh.  I cannot
do that at the moment, but are we close to that status again?

(2) Joao: your last message seemed rather irritated by my changes, but
please think of this as one step in a process rather than the final perfect
solution.  I have carefully read your e-mails on this subject, and I believe
others here have as well (and I also hope Geoffrey makes a special effort to
do so when he gets back).  If I read you correctly, you want to split
libraries up some more beyond what I have done already.  I am not against
that at all.  In fact, I would love to see tclAPI.c get more and more lonely
in its library to make it as parallel as possible with the nice clean
interface we have for python. So I am basically on your side.  But I was
concerned your arguments did not take library linking constraints into
account which are absolutely dictated by the source file contents. However,
if you can find a way to do what you want without introducing reverse
linking (see below), I would have no objection at all.

(3) IMPORTANT Shared library linking constraints:

Here is the deal as I understand it.  Suppose in Linux you have liba
depending on libx and libx depending on liby.  What I mean by "depending on"
here is that liba requires some functions that are defined in libx and libx
requires some functions that are defined in liby.  Special note: these
dependencies are completely dictated by the content of the C code, i.e., the
actual objects that get put into each library.  Also, it is important to
have the dependencies one way only to avoid cross-dependency issues (and of
course that was the motivation for splitting xwin and tkwin.)

In Linux you can be completely sloppy about the way you link liba, libx, and
liby together and also the way you link your applications.  For example, you
can link liba to liby and liby to libx and your applications to liba and it
or any other permutation will work on Linux!  But it won't work
cross-platform because some platforms demand only forward linking, e.g.,
reverse-linking (against the dependency) liby to libx won't work on some
platforms.

For cross-platform use the safe way to do things for the above dependency
heirarchy is to link to the highest members in the hierarchy that a given
application or library is dependent on.  That is, link your applications
only to liba, liba only to libx, and libx only to liby. That will continue
to work fine on Linux.  But for cross-platform use one more step is
required; you must use libtool to translate automatically for each platform
this hiearchy of dependencies you have specified into something that works
fine for each platform.  libtool handles all the details of taking account
of the linker limitations of every platform.  But my understanding from
reading the libtool documentation is if you build in reverse linking or
cross linking, you are hosed!

The current status is the linking changes I made today are consistent with
the hierarchical rule above and the known linking dependencies that we have
as dictated by the current contents of the libraries.  libplplottcktk
depends on and links to libplplot and libtclmatrix; all dynamic drivers
other than xwin, tkwin, and tk depend on and link to libplplot; the xwin,
tkwin, and tk drivers depend both on libplplottcktk and libplplot, but only
link to libplplottcktk (the higher member in the hierarchy); and libplplot
and libtclmatrix depend on no other libraries in plplot so link to none of
them. No library depends on a dynamic driver. Most applications (e.g., x01c,
plrender) depend only on libplplot so that is all they link to. pltcl and
plserver depend both on libplplottcktk and libplplot, but only need to link
to the higher member, libplplottcktk.

Joao, if you decide to split or reorganize the libraries (including dynamic
drivers) some more, please be really careful of the dependencies (dictated
by exactly which functions you put into the various libraries and dynamic
drivers) so that your changes do not introduce cross-linking, reverse
linking, or linking of libraries to dynamic drivers again.  Such a mess
would probably work on Linux, but would destroy the potential we have at the
moment for nice cross-platform handling of our linking with libtool.

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
__________________________

Re: [Plplot-devel] xwin.c is now split

[Maurice L. <mj...@ga...>]

I've been following this discussion but been too busy to comment until
now.

I agree Joao that the best design would be to NOT put xwin_common.o in
libpltcltk, that it should go in a separate library e.g. libplxwin.  OTOH
Alan's argument that it should go in libpltcltk as a pragmatic issue (to save
work, simplify, etc) is compelling.  So I can be happy with Alan's choice.

One possibility that might satisfy everyone, if it could work, is to use
an escape function in the xwin driver for the missing commands.  Then there
is separation without significant increase in work.  Has anyone looked into
this approach?

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] xwin.c is now split

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

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

Re: [Plplot-devel] xwin.c is now split

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

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

Re: [Plplot-devel] xwin.c is now split

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

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

Re: [Plplot-devel] xwin.c is now split

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

On Thursday 25 July 2002 09:34, 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...

Yes. And this fully justifies what you say in another mail:

|> 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?=20
|or xtk? or tkall? The directory name in the bindings directory is=20
|already 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'=20
| driver is).  If anything we should rename 'tk' to 'tkx' and take=20
| 'tk' for the new driver *grin*.

I agree, but historical considerations... if/when the tkwin driver=20
becomes a standalone driver, the old tk driver could disappear, but=20
I'm sure that many people would be against this...

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

Re: [Plplot-devel] xwin.c is now split

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

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

Re: [Plplot-devel] Define size of graphic / setting background color

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

I just checked, and indeed I did commit that change from Gary 5 weeks ago.
But I totally forgot about it because there has been *a lot* of other CVS
commits since.

BTW, if you want to avoid the instability of using CVS HEAD, the differences
between Gary's version and the 5.0.1 version can be seen at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/plplot/plplot/drivers/pbm.c.diff?r1=1.8&r2=1.9

Hope that change solves your problem, Stefan!

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 Thu, 25 Jul 2002, Gary Bishop wrote:

> The version of pbm.c in CVS addresses both of these concerns. I needed
> the same capability so I added it...
>
> gb
>
>
> -------------------------------------------------------
> 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
>

Re: [Plplot-devel] Define size of graphic / setting background color

[Gary B. <gb...@cs...>]

The version of pbm.c in CVS addresses both of these concerns. I needed 
the same capability so I added it...

gb

[Plplot-devel] xwin.c is now split

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

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
__________________________

Re: [Plplot-devel] Define size of graphic / setting background color

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

Stefan, my feeling is the pbm device is currently rather poorly supported. I
suggest you use the ps device (which automatically gives black on white
postscript) instead.  That's the one I use for scientific publications.

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 Thu, 25 Jul 2002 ste...@ks... wrote:

> Hello,
>
> I just started using plplot for my project and I really like it so far. I'm
> writing some code in C which uses the plplot-lib.
>
> But two small(??)  problems occured:
>
> 1. I didn't find out how to set the size of the output-graphics. It's
> always 640x480 pixel (pbm). I already tried --geometrie and plspage, but
> both with no success.
>
> 2. Since I want a graphics black on white background I've tried to set the
> backround-color using 'plscolbg(0xFF,0xFF,0xFF);', but the result is still
> white on black background.
>
> Anyone here got an idea how to solve my two problems ??
>
>
> Thanks in advance,
>       Stefan
>
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

[Plplot-devel] Define size of graphic / setting background color

[<ste...@ks...>]

Hello,

I just started using plplot for my project and I really like it so far. I'm
writing some code in C which uses the plplot-lib.

But two small(??)  problems occured:

1. I didn't find out how to set the size of the output-graphics. It's
always 640x480 pixel (pbm). I already tried --geometrie and plspage, but
both with no success.

2. Since I want a graphics black on white background I've tried to set the
backround-color using 'plscolbg(0xFF,0xFF,0xFF);', but the result is still
white on black background.

Anyone here got an idea how to solve my two problems ??


Thanks in advance,
      Stefan

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

[Vince D. <vi...@sa...>]

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

[Vince D. <vi...@sa...>]

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

[Vince D. <vi...@sa...>]

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.

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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.

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

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

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

Re: [Plplot-devel] Splitting off libpltcl and greatly simplifying library linking options

[Maurice L. <mj...@ga...>]

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)