Re: [Plplot-devel] dyn-drivers linking -- again!

[Joao C. <jca...@in...>]

On Friday 30 November 2001 16:52, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
|  > Sorry, I meant, using
|  >
|  > =09driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)
|  >
|  > Well, I followed your recipe and build java (jdk-1.1.8). Python
|  > demos, Java demos and Octave demos all run OK with the png device (a=
s
|  > well as other fiole devices), using only the above driverslibs.
|
| Hi all,
|
| Sorry for my unresponsiveness.  I'm totally overwhelmed with other
| stuff.
|
| A quick comment on this business.  I have not been confused by the
| behavior that has been reported.  I think a sufficiently careful study
| of the emails that were exchanged earlier this fall, would make it all
| make sense.  But it is certainly frustrating, no argument there.
|
| The fix mentioned above should work.  Drivers should only depend on
| libplplot.so, plus whatever driver specific support libs they might
| need.  The dyndrv.in currently makes no effort to figure out exactly
| and only which libs are appropriate to each driver.  It would be great
| to fix that, although also laborious, which is why I never did it.

Well, I have already make it. E.g.

drivers/gd.drv : shared/gd$O
        $(SHLIB_BUILD) $@ $< @GDLIBS@ $(driverlibs)

Where GDLIBS are the libs "configure" found necessary. The other drivers =
that=20
have special libs are the gnome driver, with GNOMELIBS, and the ntk drive=
r,=20
with TKLIBS. All the other drivers only link against libplplot. Of course=
 the=20
xwin and tk drivers are static.

| The best fix, however, is to do some code development to break even
| the dependence upon libplplot.so, leaving only the (potential)
| dependence of a driver upon some external libs (gd, X11, whatever).
|
| The way to do this is to embellish the driver interface so that when a
| driver is inited, you pass in a struct, which contains members that
| are function pointers:
|
| struct plenv {
|
|     void (*plapi_xyzcall)( PLINT x, ... );
|     ...
|  };
|
| So, plcore would make one of thiese, fill in the function pointers
| with the values of (addresses of) the various PLplot API function
| entry points that might be conceivably needed by drivers,

I dont think this is practical.

| and then
| pass this struct into the driver when init'ing it.  Then the drivers
| store this, and make all their calls to the PLplot API via:
|
|     plenv->plapi_xyzcall( x, ... );
|
| etc.
|
| This breaks the linkage requirement of drivers upon libplplot.so.
|
| Doing it this way would follow in the footsteps of the Java Native
| Interface, and, I think Vince said earlier, the TEA model.
|
| At this point I can only offer this sketch, I cannot commit to
| implement anytime soon.

I think that the current scheme is reasonable, so you can spend your=20
available time improving the library itself. Have you noticed that in the=
=20
last few years only configure issues have been addressed? No significant=20
improvements to the library itself have been made?

Joao