Re: [Plplot-devel] tkwin doesn't work as dynamic driver :(

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

On Fri, 12 Jul 2002, Vince Darley wrote:

> Just build a shared library and off you go.

The light dawns....  Before I thought dll's and shared libraries were
structurally different (i.e., compiled with different flags).  However, a
google search on the phrase "linux dll" turned up an article which said they
were the same, and a look at the flags for creating, e.g., the ntk device
dll, ntkd.drv, confirm this.

So I guess the only remaining distinction to make in Linux is whether the
dll is loaded under your code's direct control by a call to dlopen (as
occurs in plcore.c, for example with the device dll's) or whether it is
loaded automatically when your programme is first loaded (or as an indirect
result of calling dlopen for a library that is linked against another
library).

That suggests an easy solution for the problems I was having with making
tkwin a dll.  As an experiment I will link libplplot against tkwind.drv.
I believe that will resolve the symbols that were unresolved before.

If/when that part of the mental model is confirmed, then I will look at
splitting off the tcl/tk stuff (as libtclplplot, say) from libplplot.  This
will mean I will drop the experiment, e.g., libplplot will no longer be
linked against tkwind.drv.  Instead, libtclplplot will be linked against
tkwind.drv and libplplot.  Then applications will only be linked against
libtclplplot in special cases (such as pltcl and plserver) where tcl/tk is
actually being used.  And if the mental model is correct, then simply
loading libtclplplot from wish is all that will be required to automatically
load every dll that will be needed.

Let me know if there are any problems with the revised mental model of
the dynamic linking process.

Assuming there are no such problems I will go ahead with the experiment and
if that works the splitting, and if that also works under Linux I will
commit the results to CVS HEAD so others will be able try it out.

Alan