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