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