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